[22413] in Perl-Users-Digest
Perl-Users Digest, Issue: 4634 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 27 14:06:07 2003
Date: Thu, 27 Feb 2003 11:05: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, 27 Feb 2003 Volume: 10 Number: 4634
Today's topics:
Re: Also religious: brackets <newsfeed2@boog.co.uk>
Re: Also religious: brackets <uri@stemsystems.com>
Re: Also religious: brackets <ubl@schaffhausen.de>
Re: Also religious: brackets <steven.smolinski@sympatico.ca>
Re: Also religious: brackets <tzz@lifelogs.com>
Re: Also religious: brackets <uri@stemsystems.com>
Re: Also religious: brackets <tzz@lifelogs.com>
Re: Also religious: brackets <uri@stemsystems.com>
Re: Anyway to do away with ?: in the map function <shondell@cis.ohio-state.edu>
Re: Anyway to do away with ?: in the map function <oxmard.Rules@ab.ab>
Re: Anyway to do away with ?: in the map function <shondell@cis.ohio-state.edu>
Re: Anyway to do away with ?: in the map function (Anno Siegel)
Re: Can't set or access array element in struct (Carlton Brown)
Re: Can't set or access array element in struct (Anno Siegel)
Re: Including my perl functions in one file in another <barryk2@SPAM-KILLER.mts.net>
Re: Necessary modules? <newsfeed2@boog.co.uk>
Re: Necessary modules? <edgue@web.de>
Newbie: Trouble with time() from "learning perl" book e (cayenne)
Re: Newbie: Trouble with time() from "learning perl" bo <shondell@cis.ohio-state.edu>
Problem with DBM module <texier@ebi.ac.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 27 Feb 2003 16:11:32 -0000
From: "Peter Cooper" <newsfeed2@boog.co.uk>
Subject: Re: Also religious: brackets
Message-Id: <XLq7a.6401$EN3.50675@newsfep4-glfd.server.ntli.net>
> *verbose* is very different from *debug*. If I see C<$debug and...> in
> my code I can say "This line is irrelevant for normal program execution"
> at first glance. I don't have to read all of the line to get that
> information.
I agree. In fact, I never use the "blah blah IF so and so" convention in Perl. I
either use a full proper if block, or, in cases where it's something like a
debug or verbose.. I do it " $flag && whatever".. since $flag is literally that,
a flag.. and that line immediately tells me it'll only run if $flag is true.
Besides, I find placing the 'if' at the end of a line to be rather inconsistent
with other common programming languages, and therefore the 'mindset' I learnt
while coming up through BASIC, Pascal, C, C++, etc.
Wordiness is no virtue. For evidence, see Pascal vs C :-)
Still, TMTOWTDI, and that's the great thing about Perl.
Pete
------------------------------
Date: Thu, 27 Feb 2003 16:20:03 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Also religious: brackets
Message-Id: <x7isv5elvy.fsf@mail.sysarch.com>
>>>>> "PC" == Peter Cooper <newsfeed2@boog.co.uk> writes:
>> *verbose* is very different from *debug*. If I see C<$debug and...> in
>> my code I can say "This line is irrelevant for normal program execution"
>> at first glance. I don't have to read all of the line to get that
>> information.
PC> I agree. In fact, I never use the "blah blah IF so and so"
PC> convention in Perl. I either use a full proper if block, or, in
PC> cases where it's something like a debug or verbose.. I do it "
PC> $flag && whatever".. since $flag is literally that, a flag.. and
PC> that line immediately tells me it'll only run if $flag is true.
PC> Besides, I find placing the 'if' at the end of a line to be rather
PC> inconsistent with other common programming languages, and
PC> therefore the 'mindset' I learnt while coming up through BASIC,
PC> Pascal, C, C++, etc.
fewer lines and less use of braces are also nice. i always use braces in
c for if/while blocks as they visually highlight a conditional. too
often you see (check out some gnu emacs code) deeply nested code with no
braces. besides the dangling else bugs that await, you can't read it
even with clean indenting.
the difference with perl's statement modifiers is that they can't be
nested. this removes any dangling else bug possibility and the need for
massive indenting for nested stuff.
the general rule about fewer lines of code means fewer bugs applies
here. many studies have shown that bug count is directly correlated to
line count and braces count as lines.
next if /^$/ ;
is much clearer than:
if ( /^$/ ) {
next ;
}
and is 2 lines shorter with no extra indent.
PC> Wordiness is no virtue. For evidence, see Pascal vs C :-)
which is support for statement modifiers.
now, they have to be used properly. very long statement bodies and long
conditionals can ruin their clarity. then switching to if blocks makes
sense. but for the very common and short cases they are much better IMO
than the equivilent block forms.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: Thu, 27 Feb 2003 17:34:13 +0100
From: Malte Ubl <ubl@schaffhausen.de>
Subject: Re: Also religious: brackets
Message-Id: <b3lht0$28j$1@news.dtag.de>
Peter Cooper wrote:
> I agree. In fact, I never use the "blah blah IF so and so" convention in Perl. I
> either use a full proper if block, or, in cases where it's something like a
> debug or verbose.. I do it " $flag && whatever".. since $flag is literally that,
> a flag.. and that line immediately tells me it'll only run if $flag is true.
> Besides, I find placing the 'if' at the end of a line to be rather inconsistent
> with other common programming languages, and therefore the 'mindset' I learnt
> while coming up through BASIC, Pascal, C, C++, etc.
Personally, I think that "expression modifier condition" is one of the
prettiest syntaxes ever invented for a programming language.
Unfortunately, my brain make me write:
print if /^regEx$/ while <$_> for someFileHandles
ten times a day which is a syntax error because chaining expression
modifiers is not allowed. Hmm, maybe that's not such a bad idea :)
->malte
------------------------------
Date: Thu, 27 Feb 2003 16:40:12 GMT
From: Steven Smolinski <steven.smolinski@sympatico.ca>
Subject: Re: Also religious: brackets
Message-Id: <Mbr7a.11275$os6.830066@news20.bellglobal.com>
Malte Ubl <ubl@schaffhausen.de> wrote:
> Unfortunately, my brain make me write:
>
> print if /^regEx$/ while <$_> for someFileHandles
>
> ten times a day which is a syntax error because chaining expression
> modifiers is not allowed. Hmm, maybe that's not such a bad idea :)
\begin{plea}
Won't somebody *please* think of the maintainers?!
\end{plea}
:-)
Steve
--
Steven Smolinski => http://arbiter.ca/
GnuPG Public Key => http://arbiter.ca/steves_public_key.txt
=> or email me with 'auto-key' in the subject.
Key Fingerprint => 08C8 6481 3A7B 2A1C 7C26 A5FC 1A1B 66AB F637 495D
------------------------------
Date: Thu, 27 Feb 2003 12:22:45 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Also religious: brackets
Message-Id: <4nd6ldk596.fsf@chubby.bwh.harvard.edu>
On Thu, 27 Feb 2003, uri@stemsystems.com wrote:
> the general rule about fewer lines of code means fewer bugs applies
> here. many studies have shown that bug count is directly correlated
> to line count and braces count as lines.
By your logic and according to those studies, if I condense all my
programs into one line, I will automatically reduce the probability of
bugs to be 1/N where N was the old number of lines. At the very
least, rewriting all my
if (...)
{
...
}
statements to
if (...) { ... }
will reduce the probability of bugs by a non-zero percentage!
I like it! Thanks!
Ted
------------------------------
Date: Thu, 27 Feb 2003 17:27:40 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Also religious: brackets
Message-Id: <x765r5eir8.fsf@mail.sysarch.com>
>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
TZ> On Thu, 27 Feb 2003, uri@stemsystems.com wrote:
>> the general rule about fewer lines of code means fewer bugs applies
>> here. many studies have shown that bug count is directly correlated
>> to line count and braces count as lines.
TZ> By your logic and according to those studies, if I condense all my
TZ> programs into one line, I will automatically reduce the probability of
TZ> bugs to be 1/N where N was the old number of lines. At the very
TZ> least, rewriting all my
TZ> if (...)
TZ> {
TZ> ...
TZ> }
TZ> statements to
TZ> if (...) { ... }
TZ> will reduce the probability of bugs by a non-zero percentage!
TZ> I like it! Thanks!
bah.
ever heard of diminishing returns?
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: Thu, 27 Feb 2003 13:39:01 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Also religious: brackets
Message-Id: <4n8yw1k1q2.fsf@chubby.bwh.harvard.edu>
On Thu, 27 Feb 2003, uri@stemsystems.com wrote:
>>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>
> TZ> On Thu, 27 Feb 2003, uri@stemsystems.com wrote:
> >> the general rule about fewer lines of code means fewer bugs
> >> applies here. many studies have shown that bug count is
> >> directly correlated to line count and braces count as lines.
>
> TZ> By your logic and according to those studies, if I condense
> TZ> all my programs into one line, I will automatically reduce the
> TZ> probability of bugs to be 1/N where N was the old number of
> TZ> lines. At the very least, rewriting all my
> TZ> statements to
>
> TZ> if (...) { ... }
>
> TZ> will reduce the probability of bugs by a non-zero percentage!
> bah.
>
> ever heard of diminishing returns?
I think it's obvious the first part was not serious. But you have to
admit that claiming that the multi-line if() statement is more prone
to bugs than a single-line post-modifier because "braces count as
lines" is silly. At the very least, you are claiming that all C code
without braces for single-line if() blocks is implicitly less buggy
than C code which uses braces for single-line if() blocks.
Braces are not lines of code. They can be on a line of their own, but
all the studies are relevant to lines of code, not lines in the
program.
Also, lines of code is widely considered to be an ineffective metric,
and does not take into consideration a number of code aspects. This
is especially relevant to languages like Perl, where a single line of
code (without tricks like merging statements or multiple assignments)
can be as highly complex as a page of C. So I disagree with your
statement on a more fundamental level than just "braces count as
lines."
Ted
------------------------------
Date: Thu, 27 Feb 2003 19:03:36 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Also religious: brackets
Message-Id: <x7vfz5czqw.fsf@mail.sysarch.com>
>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
TZ> Braces are not lines of code. They can be on a line of their own, but
TZ> all the studies are relevant to lines of code, not lines in the
TZ> program.
TZ> Also, lines of code is widely considered to be an ineffective metric,
TZ> and does not take into consideration a number of code aspects. This
TZ> is especially relevant to languages like Perl, where a single line of
TZ> code (without tricks like merging statements or multiple assignments)
TZ> can be as highly complex as a page of C. So I disagree with your
TZ> statement on a more fundamental level than just "braces count as
TZ> lines."
the real point is that 'unnecessary' extra braces and indents can
obscure the code. reducing their use by using statement modifiers is a
good thing for that reason alone. it makes the code easier to read and
maintain. it also makes it easier to see more of the code on a screen or
printed page which is good. but then i like more white space than most
which counteracts that. my underlying goal is to get coders to think
about their code as a result in itself and not just a way to get the
program working. clarity is the goal and statement modifiers if used
properly greatly improve clarity.
and better clarity will lead to fewer bugs as well.
so the line metric idea is still true but should be understood as
slightly humorous and not an absolute goal in itself. i know what perl
golf is all too well. :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
------------------------------
Date: 27 Feb 2003 11:43:27 -0500
From: Ryan Shondell <shondell@cis.ohio-state.edu>
Subject: Re: Anyway to do away with ?: in the map function
Message-Id: <xcwsmu9oes0.fsf@psi.cis.ohio-state.edu>
Please don't top-post. Text rearranged chronologically...I think.
"Peter Shankey" <oxmard.Rules@ab.ab> writes:
> "Tore Aursand" <tore@aursand.no> wrote in message
> news:pan.2003.02.26.22.55.25.710423@aursand.no...
> > Just a tip; Try to avoid using 'map' in a void context.
>
>
> I did run into some warning messages when I was trying to use map. Any
> particular reason why?
>
Well, what Tore was talking about doesn't generate a warning (at
least, I don't think it does...). map returns a list, and using it in
a void context means you're just throwing that list away. Why create
it if you're not going to use it?
As for the warnings...what did they say? Try adding
use diagnostics;
to your code and it will tell you more about your warnings.
Ryan
--
perl -e '$;=q,BllpZllla_nNanfc]^h_rpF,;@;=split//,
$;;$^R.=--$=*ord for split//,$~;sub _{for(1..4){$=
=shift;$=--if$=!=4;while($=){print chr(ord($;[$%])
+shift);$%++;$=--;}print " ";}}_(split//,$^R);q;;'
------------------------------
Date: Thu, 27 Feb 2003 11:56:18 -0600
From: "Peter Shankey" <oxmard.Rules@ab.ab>
Subject: Re: Anyway to do away with ?: in the map function
Message-Id: <n_OcnZfpRaP9zMOjXTWcow@comcast.com>
"Ryan Shondell" <shondell@cis.ohio-state.edu> wrote in message
news:xcwsmu9oes0.fsf@psi.cis.ohio-state.edu...
> Please don't top-post. Text rearranged chronologically...I think.
>
> "Peter Shankey" <oxmard.Rules@ab.ab> writes:
>
> > "Tore Aursand" <tore@aursand.no> wrote in message
> > news:pan.2003.02.26.22.55.25.710423@aursand.no...
> > > Just a tip; Try to avoid using 'map' in a void context.
> >
> >
> > I did run into some warning messages when I was trying to use map. Any
> > particular reason why?
> >
>
> Well, what Tore was talking about doesn't generate a warning (at
> least, I don't think it does...). map returns a list, and using it in
> a void context means you're just throwing that list away. Why create
> it if you're not going to use it?
>
> As for the warnings...what did they say? Try adding
>
> use diagnostics;
>
> to your code and it will tell you more about your warnings.
>
>
> Ryan
I should have been clearer about the warnings. When I started working with
map I was getting warnings. The final code is not. I did put 'use
diagnostics;' in the code. Thank you for explaining what Tore was getting
at. I understand what Tore was getting at. I am indeed not using the list
returned by map. I could not figure out a way to return the list and have it
be what I wanted. I tried some stuff line:
print $_->[0], $_->[1], $_->[2], $_->[3] for map ....
however I would still get a newline returned to $_->[0] non matching line. I
could not figure out a way to test for this.
I found I could get just the data I wanted into an array. This is fine for
the small sample but for a very very large amount of data the RAM on the
host was being used up. My goal with the map function was to 'grep' and
'split' the data in one pass. My ulitate goal is to load data as quickly as
possible into an Oracle DB. If you know a way to this let me know. Here is
the code and a small sample of the data:
use strict;
use warnings;
use diagnostics;
use DBI;
my $dbh = DBI->connect('dbi:Oracle:to5',
'scott',
'tiger',
{RaiseError => 1,
PrintError => 0,
AutoCommit => 0})
or die "Unable to connect $DBI::errstr";
map {
/ values \((\w*),('[\W*|\w*]*'),([\w]*),([\w]*)/
?($dbh->do("insert into customers values ( $1, $2, $3, $4 ) ")):()}
<DATA>;
$dbh->commit;
$dbh->disconnect();
__DATA__
/* comment commnet */
line of junk
/* Needs to be changed as the & is being used in the company column */
set define ~
will need to drop table customers;
will need to create table customers
line of junk
values (2111,'JCP Inc.',103,50000);
line of junk
values (2102,'First Corp.',101,65000);
insert into customers (cust_num, company, cust_rep, credit_limit)
values (2103,'Acme Mfg',105,50000);
another line of junk I do not want
values (2123,'Carter & Sons',102,40000);
values (2107,'Ace International',110,35000);
values (2115,'Smithson',101,20000);
I do not want this line
values (2101,'Jones Mfg.',106,65000);
values (2112,'Zeta corp',108,50000);
commit;
set define &
__END__
------------------------------
Date: 27 Feb 2003 13:09:49 -0500
From: Ryan Shondell <shondell@cis.ohio-state.edu>
Subject: Re: Anyway to do away with ?: in the map function
Message-Id: <xcwd6ldoas2.fsf@psi.cis.ohio-state.edu>
"Peter Shankey" <oxmard.Rules@ab.ab> writes:
(snip map warnings/diagnostics stuff)
> My goal with the map function was to 'grep' and 'split' the data in
> one pass. My ulitate goal is to load data as quickly as possible
> into an Oracle DB. If you know a way to this let me know. Here is
> the code and a small sample of the data:
>
>
> use strict;
> use warnings;
> use diagnostics;
> use DBI;
>
> my $dbh = DBI->connect('dbi:Oracle:to5',
> 'scott',
> 'tiger',
> {RaiseError => 1,
> PrintError => 0,
> AutoCommit => 0})
> or die "Unable to connect $DBI::errstr";
>
> map {
> / values \((\w*),('[\W*|\w*]*'),([\w]*),([\w]*)/
> ?($dbh->do("insert into customers values ( $1, $2, $3, $4 ) ")):()}
> <DATA>;
I guess the point really, is why use map if you're not using it's
return value? Instead of the map can you do...
foreach (my $line = <DATA>) {
next unless $line =~ /values \((\w*),('[\W*|\w*]*'),([\w]*),([\w]*)/;
$dbh->do("insert into customers values ( $1, $2, $3, $4 ) ");
}
(untested)
This seems to do the same thing.
--
perl -e '$;=q,BllpZllla_nNanfc]^h_rpF,;@;=split//,
$;;$^R.=--$=*ord for split//,$~;sub _{for(1..4){$=
=shift;$=--if$=!=4;while($=){print chr(ord($;[$%])
+shift);$%++;$=--;}print " ";}}_(split//,$^R);q;;'
------------------------------
Date: 27 Feb 2003 18:46:03 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Anyway to do away with ?: in the map function
Message-Id: <b3lmdb$c23$1@mamenchi.zrz.TU-Berlin.DE>
Peter Shankey <oxmard.Rules@ab.ab> wrote in comp.lang.perl.misc:
>
> "Ryan Shondell" <shondell@cis.ohio-state.edu> wrote in message
> news:xcwsmu9oes0.fsf@psi.cis.ohio-state.edu...
> > Please don't top-post. Text rearranged chronologically...I think.
> >
> > "Peter Shankey" <oxmard.Rules@ab.ab> writes:
> >
> > > "Tore Aursand" <tore@aursand.no> wrote in message
> > > news:pan.2003.02.26.22.55.25.710423@aursand.no...
> > > > Just a tip; Try to avoid using 'map' in a void context.
> > >
> > >
> > > I did run into some warning messages when I was trying to use map. Any
> > > particular reason why?
> > >
> >
> > Well, what Tore was talking about doesn't generate a warning (at
> > least, I don't think it does...). map returns a list, and using it in
> > a void context means you're just throwing that list away. Why create
> > it if you're not going to use it?
> >
> > As for the warnings...what did they say? Try adding
> >
> > use diagnostics;
> >
> > to your code and it will tell you more about your warnings.
> >
> >
> > Ryan
>
>
> I should have been clearer about the warnings. When I started working with
> map I was getting warnings. The final code is not. I did put 'use
> diagnostics;' in the code. Thank you for explaining what Tore was getting
> at. I understand what Tore was getting at.
It doesn't quite look like it. The code below is the same you posted
in your original post. So far, you have taken none of the hints in
this thread.
> I am indeed not using the list
> returned by map. I could not figure out a way to return the list and have it
> be what I wanted. I tried some stuff line:
> print $_->[0], $_->[1], $_->[2], $_->[3] for map ....
> however I would still get a newline returned to $_->[0] non matching line. I
> could not figure out a way to test for this.
> I found I could get just the data I wanted into an array. This is fine for
> the small sample but for a very very large amount of data the RAM on the
> host was being used up. My goal with the map function was to 'grep' and
> 'split' the data in one pass.
But if you're worried about space, map is exactly what you don't want
to use. Not because it returns a list, but because it also *takes* a
list as an argument. In your case this means that the whole file must
be read into memory before map() can even begin. What you want is deal
with the file line by line.
> My ulitate goal is to load data as quickly as
> possible into an Oracle DB. If you know a way to this let me know. Here is
> the code and a small sample of the data:
>
>
> use strict;
> use warnings;
> use diagnostics;
> use DBI;
>
> my $dbh = DBI->connect('dbi:Oracle:to5',
> 'scott',
> 'tiger',
> {RaiseError => 1,
> PrintError => 0,
> AutoCommit => 0})
> or die "Unable to connect $DBI::errstr";
>
> map {
> / values \((\w*),('[\W*|\w*]*'),([\w]*),([\w]*)/
This regex is pretty botched and works more by coincidence than by
design. DWIM may be a good thing, but sometimes I hate it.
For the data you show, split() is the better tool anyway, so I won't try
to correct it.
> ?($dbh->do("insert into customers values ( $1, $2, $3, $4 ) ")):()}
You do a *lot* of work inside the map block. This is often (not always)
a sign that map() is misapplied, apart from not using the returned list.
> <DATA>;
This innocent-looking line slurps all the data into memory.
> $dbh->commit;
> $dbh->disconnect();
I'm not commenting the DBI stuff, I know nothing about that.
Instead of map(), use a simple loop over the data lines:
while ( <DATA> ) {
next unless /^ values/; # skip unwanted lines
chomp;
# use meaningful names in the next line instead of $d1 .. $d4
( undef, my ( $d1, $d2, $d3, $d4)) = split /[(),]/;
$dbh->do(
"insert into customers values ( $d1, $d2, $d3, $d4 )"
); # whatever
}
[data snipped]
This won't make it much faster, but it will save space. Someone else
in this thread has mentioned prepare() and related methods of DBI.
If applicable, these could be time savers.
Anno
------------------------------
Date: 27 Feb 2003 09:29:33 -0800
From: carltonbrown@hotmail.com (Carlton Brown)
Subject: Re: Can't set or access array element in struct
Message-Id: <aa611a32.0302270929.46a0c90f@posting.google.com>
>
> > print "His aliases are: ", join(", ", @{mage->aliases}), ".\n";
> ^^
> ^^
>
> Where is the dollar sign for the $mage variable?
My bad, it must have gotten lost in the cut-and-paste. Other than
that, the code is the same, and the results are the same as I
described:
person.pl script follows:
#!/usr/bin/perl
use Person;
my $mage = Person->new;
$mage->name("Gandalf");
$mage->race("Istar");
$mage->aliases( ["Mithrandir","Olorin","Incanus"] );
printf "%s is of the race of %s.\n", $mage->name, $mage->race;
print "His aliases are: ", join(", ", @{$mage->aliases}), ".\n";
Person.pm module follows:
package Person;
use Class::Struct;
struct Person => {
name => '$',
race => '$',
aliases => '@',
};
1;
------------------------------
Date: 27 Feb 2003 18:00:26 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Can't set or access array element in struct
Message-Id: <b3ljnq$a4v$1@mamenchi.zrz.TU-Berlin.DE>
Carlton Brown <carltonbrown@hotmail.com> wrote in comp.lang.perl.misc:
> >
> > > print "His aliases are: ", join(", ", @{mage->aliases}), ".\n";
> > ^^
> > ^^
> >
> > Where is the dollar sign for the $mage variable?
>
> My bad, it must have gotten lost in the cut-and-paste. Other than
> that, the code is the same, and the results are the same as I
> described:
No, the missing "$" accounts exactly for the error message
Can't locate object method "aliases" via package "mage" ...
you've seen. With the "$" your code (which I snipped) works as expected.
Anno
------------------------------
Date: Thu, 27 Feb 2003 08:23:59 -0600
From: Barry Kimelman <barryk2@SPAM-KILLER.mts.net>
Subject: Re: Including my perl functions in one file in another perl script file
Message-Id: <MPG.18c7db7d4a3d925298971e@news.mts.net>
In article <da669e11.0302270514.576102c9@posting.google.com>, Warren
Ayling (warren_ayling@hotmail.com) says...
> I have been reading various Perl books and searching the Perl Google
> group but with little luck.
>
> Is there any way to include Perl functions in one file, in anther Perl
> file, e.g.:
>
> include "../utils/my_perl_utils";
>
> I am new to Perl but have already collected and written some great
> utility functions that I would like to be able to reuse in other
> scripts.
>
> Do I have to compile them into a module before I can reuse them?
>
> Many thanks
>
require "../utils/my_perl_utils";
Note : the last line of "../utils/my_perl_utils" MUST end with
the line
1;
(it must be a TRUE expression)
--
---------
Barry Kimelman
Winnipeg, Manitoba, Canada
email : bkimelman@hotmail.com
------------------------------
Date: Thu, 27 Feb 2003 16:14:26 -0000
From: "Peter Cooper" <newsfeed2@boog.co.uk>
Subject: Re: Necessary modules?
Message-Id: <MOq7a.6404$EN3.50770@newsfep4-glfd.server.ntli.net>
> To get a more complete list, you can insert a coderef into @INC
> that prints out every module that is searched for:
>
> BEGIN { unshift @INC, sub { warn "loading $_[ 1]\n"; return } }
Bravo. I've never seen that Perl trick before. Delightful in its simplicity!
Pete
------------------------------
Date: Thu, 27 Feb 2003 17:16:51 +0100
From: Edwin Guenthner <edgue@web.de>
Subject: Re: Necessary modules?
Message-Id: <3E5E39F3.5000802@web.de>
Peter Cooper wrote:
> Bravo. I've never seen that Perl trick before. Delightful in its simplicity!
Yes, neat that is. But it didnt tell me much more; just some
three or four names more.
Maybe I should reverse my question:
Which modules would be good candidates to not compile them
into my perl.exe? "Good" in the sense of
- they are large
- they are not required by other built-in modules of P5.8?
------------------------------
Date: 27 Feb 2003 08:56:49 -0800
From: chilecayenne@yahoo.com (cayenne)
Subject: Newbie: Trouble with time() from "learning perl" book example...please help explain?
Message-Id: <2deb3d1.0302270856.6d55bdad@posting.google.com>
Hello all,
I'm just starting to learn some Perl. I'm using Linux RH 7.2. I'm
working through the first chapter of the O'Reilly book, Learning Perl.
There is the part where you are storing the last guess of a password
into a local database using dbopen.
The lines:
dbopen(%last_good,"lastdb",0666);
$last_good{$name} = time;
dbmclost (%last_good);
Are used to store the last time a user successfully guessed his
password.
There is another small program to give a report from this db:
#!/usr/bin/perl
dbmopen (%last_good,"lastdb",0666) || die "Cannot dbopen lastdb: $!";
foreach $name (sort keys (%last_good)) {
$when = $last_good{$namd};
$hours = (time() - $when) / 3600;
write;
}
format STDOUT =
User @<<<<<<<<<<<: last correct guess was @<<< hours ago.
$name, $hours
.
However, the results of this are:
User barney : last correct guess was 2906 hours ago.
User betty : last correct guess was 2906 hours ago.
User fred : last correct guess was 2906 hours ago.
User kelly : last correct guess was 2906 hours ago.
I put in a print statement to see what time was being stored in the
first program, and it gave me:
The time entered is: 1046364804
This doesn't appear to be the time in seconds as the example alluded
to. Can someone explain what format this time is...and how to
parse/manipulate it so that elapsed hours can be established?
TIA,
CC
------------------------------
Date: 27 Feb 2003 12:05:39 -0500
From: Ryan Shondell <shondell@cis.ohio-state.edu>
Subject: Re: Newbie: Trouble with time() from "learning perl" book example...please help explain?
Message-Id: <xcwof4xodr0.fsf@psi.cis.ohio-state.edu>
chilecayenne@yahoo.com (cayenne) writes:
> Hello all,
>
> I'm just starting to learn some Perl. I'm using Linux RH 7.2. I'm
> working through the first chapter of the O'Reilly book, Learning Perl.
> There is the part where you are storing the last guess of a password
> into a local database using dbopen.
>
> The lines:
> dbopen(%last_good,"lastdb",0666);
> $last_good{$name} = time;
> dbmclost (%last_good);
You shouldn't re-type your code. Use copy/paste. There are a number of
typos.
(snip re-typed code)
> I put in a print statement to see what time was being stored in the
> first program, and it gave me:
>
> The time entered is: 1046364804
>
> This doesn't appear to be the time in seconds as the example alluded
> to. Can someone explain what format this time is...and how to
> parse/manipulate it so that elapsed hours can be established?
It it time in seconds since midnight the 1st of Jan, 1970.
Parsing it is an exercise in Google groups searching. :-)
Ryan
--
perl -e '$;=q,BllpZllla_nNanfc]^h_rpF,;@;=split//,
$;;$^R.=--$=*ord for split//,$~;sub _{for(1..4){$=
=shift;$=--if$=!=4;while($=){print chr(ord($;[$%])
+shift);$%++;$=--;}print " ";}}_(split//,$^R);q;;'
------------------------------
Date: Thu, 27 Feb 2003 15:23:05 +0000
From: Vincent Le-Texier <texier@ebi.ac.uk>
Subject: Problem with DBM module
Message-Id: <b3lagp$onv$2@niobium.hgmp.mrc.ac.uk>
Hello,
I'm working with the DBM module and I have a big problem.
I'm trying to create a DBM file of 3 millions entries and Perl doesn't
find the good value of my hachtable.
I've seen that perl find the previous entry.
Since , with DB, you have Partail key lookups, I've created a hachtable
like this (add of a special caracter at the end of the key)
$key = "rs1" . "|";
$RS{$key} = ...
But this, doesn't work also.
With for example, 129782 entries , it's ok.
If you have an idea to solve my problem , thanks a lot.
Vincent.
------------------------------
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:
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.
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 V10 Issue 4634
***************************************
