[24304] in Perl-Users-Digest
Perl-Users Digest, Issue: 6495 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 30 18:10:49 2004
Date: Fri, 30 Apr 2004 15:10:10 -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 Fri, 30 Apr 2004 Volume: 10 Number: 6495
Today's topics:
Performance implications of using the Switch module (GreenLight)
Problem with global variables <raslebol@duspam.fr>
Re: Problem with global variables <noreply@gunnar.cc>
Re: search.pl <noreply@gunnar.cc>
Re: search.pl <spamtrap@dot-app.org>
Re: search.pl <webmaster @ infusedlight . net>
Re: search.pl <noreply@gunnar.cc>
Re: tunneling the richest cookies (GreenLight)
use constant and BEGIN don't mix? <jkrugman@yahbitoo.com>
Re: use constant and BEGIN don't mix? <jkrugman@yahbitoo.com>
Re: use constant and BEGIN don't mix? <skuo@mtwhitney.nsc.com>
Re: WHAT IS THE POINT OF FORMMAIL ? <webmaster @ infusedlight . net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 30 Apr 2004 11:05:33 -0700
From: google@milbaugh.com (GreenLight)
Subject: Performance implications of using the Switch module
Message-Id: <c4b60ce1.0404301005.4652c239@posting.google.com>
I hate looking at rows and rows of elsif statements as much as the
next person, but using the Switch module just doesn't cut it. I wrote:
use strict;
use warnings;
use Benchmark;
use Switch;
sub use_if() {
my ($tag, $value);
my @parsed;
my @tags = (
"TAG001^VALUE001", "TAG002^VALUE002", "TAG003^VALUE003",
"TAG004^VALUE004", "TAG005^VALUE005",
"TAG006^VALUE006", "TAG007^VALUE007", "TAG008^VALUE008",
"TAG009^VALUE009", "TAG010^VALUE010"
);
foreach my $next (@tags) {
($tag, $value) = ($next =~ /^(.*?)\^(.*?)$/);
if ($tag eq 'TAG001') { push @parsed, $value }
elsif ($tag eq 'TAG002') { push @parsed, $value }
elsif ($tag eq 'TAG003') { push @parsed, $value }
elsif ($tag eq 'TAG004') { push @parsed, $value }
elsif ($tag eq 'TAG005') { push @parsed, $value }
elsif ($tag eq 'TAG006') { push @parsed, $value }
elsif ($tag eq 'TAG007') { push @parsed, $value }
elsif ($tag eq 'TAG008') { push @parsed, $value }
elsif ($tag eq 'TAG009') { push @parsed, $value }
elsif ($tag eq 'TAG010') { push @parsed, $value }
else { die "Bad tag!" }
}
}
sub use_switch() {
my ($tag, $value);
my @parsed;
my @tags = (
"TAG001^VALUE001", "TAG002^VALUE002", "TAG003^VALUE003",
"TAG004^VALUE004", "TAG005^VALUE005",
"TAG006^VALUE006", "TAG007^VALUE007", "TAG008^VALUE008",
"TAG009^VALUE009", "TAG010^VALUE010"
);
foreach my $next (@tags) {
($tag, $value) = ($next =~ /^(.*?)\^(.*?)$/);
switch ($tag) {
case "TAG001" { push @parsed, $value }
case "TAG002" { push @parsed, $value }
case "TAG003" { push @parsed, $value }
case "TAG004" { push @parsed, $value }
case "TAG005" { push @parsed, $value }
case "TAG006" { push @parsed, $value }
case "TAG007" { push @parsed, $value }
case "TAG008" { push @parsed, $value }
case "TAG009" { push @parsed, $value }
case "TAG010" { push @parsed, $value }
else { die "Bad tag!" }
}
}
}
timethese (100000, {
"Using 'if'" => \&use_if,
"Using 'switch'" => \&use_switch
});
__END__
These subroutines adequately represent tasks performed thousands of
times per day at my client's site.
And the results:
Benchmark: timing 100000 iterations of Using 'if', Using 'switch'...
Using 'if': 17 wallclock secs (16.48 usr + 0.00 sys = 16.48 CPU) @
6066.49/s (n=100000)
Using 'switch': 153 wallclock secs (150.68 usr + 0.00 sys = 150.68
CPU) @ 663.68/s (n=100000)
Using "switch" was nearly an order of magnitude slower.
Now my real question: Does anyone know if the "forthcoming" Perl6
version (given/when, as described in "perldoc switch") will offer
better performance (that is, is anyone actually using any early
release and can comment upon the performance)?
------------------------------
Date: Fri, 30 Apr 2004 20:22:46 +0200
From: Florence HENRY <raslebol@duspam.fr>
Subject: Problem with global variables
Message-Id: <c6u5gv$jgf$1@carbone.net.espci.fr>
Hello,
I do not manage to propagate my global variables through all the subroutines
of my program.
I define some global variables using a module :
### pdsdb_var.pm
package pdsdb_var;
require Exporter;
@ISA = qw(Exporter);
@EXPORT_OK = qw(@columns_char @columns_num);
@columns_char = (1, 2, 3, 4, 5);
@columns_num = ("blah", "blah", "blah");
1;
__END__
### end of pdsdb_var.pm
And I use them in the main program :
#!/usr/bin/perl
use pdsdb_var qw(@columns_char @columns_num);
print @columns_char . "\n";
print @columns_num . "\n";
### end of main
Until here, it works nice. My problem is that I cannot use those global
variables from a subroutine that is defined in another package :
### pdsdb_sub.pm
package pdsdb_sub;
sub main::PrintVar {
print @columns_char . "\n";
print @columns_num . "\n";
return;
}
1;
__END__
### end of pdsdb_sub.pm
If I use this function from my main program :
#!/usr/bin/perl
use pdsdb_var qw(@columns_char @columns_num);
use pdsdb_sub;
print @columns_char . "\n";
print @columns_num . "\n";
main::PrintVar();
### end of main
the program prints :
5
3
0
0
which means that my global variables are not defined within pdsdb_sub.pm
How could I manage to propagate my global variables within all my
subroutines ?
I precise that I cannot write :
use pdsdb_var qw(@columns_char @columns_num);
within pdsdb_sub.pm because my real problem is a little more complicated
than that :
* I have several programs, and some of them share the same data (same name,
same content), and some just share the data type (same name but content
differs), so I defined several modules pdsdb_var1.pm, pdsdb_var2.pm, ...
which I include where needed.
* All the programs use the same functions defined in
pdsdb_sub.pm (so I have to use pdsdb_sub in each one). These functions are
supposed to use the variables defined in pdsdb_varX.pm, which content
differs following the main calling program.
Thanks for any help.
--
Florence Henry
florence point henry arobasse obspm point fr
------------------------------
Date: Fri, 30 Apr 2004 21:37:13 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Problem with global variables
Message-Id: <c6ua8a$gndun$1@ID-184292.news.uni-berlin.de>
Florence HENRY wrote:
> How could I manage to propagate my global variables within all my
> subroutines ?
>
> I precise that I cannot write :
>
> use pdsdb_var qw(@columns_char @columns_num);
>
> within pdsdb_sub.pm because my real problem is a little more
> complicated than that :
I didn't quite understand why you can't import those names to the
modules where they need to be used, but an alternative way to access
them is to use the fully qualified names, i.e.
@pdsdb_var::columns_char and @pdsdb_var::columns_num.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 30 Apr 2004 21:02:06 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: search.pl
Message-Id: <c6u86d$g0gqj$1@ID-184292.news.uni-berlin.de>
Robin wrote:
> Sherm Pendley wrote:
>> You should be using more helpful error messages. The above tells
>> you nothing more than that a file failed to open - it would be
>> better if it also told you what file and why. Including the file
>> name and $! would make this bug easier to find.
>
> yes, this is my first draft and I haven't really worked in the
> error checking routine, but I will....
It's rude IMO to post a "first draft" of script and ask for criticism,
since it unnecessarily takes up people's time.
Do your *best* first, and (possibly) ask for criticism only after that.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 30 Apr 2004 16:05:54 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: search.pl
Message-Id: <LL2dnec7pq4_LA_dRVn-ig@adelphia.com>
Robin wrote:
> "Sherm Pendley" <spamtrap@dot-app.org> wrote in message
> news:Ad6dnQgBHIYXYQzdRVn-jA@adelphia.com...
>>
>> Your script passes the directory to parse(), but it doesn't look like
>> parse() is using it. So any file that isn't in the current directory
> ('./')
>> won't get parsed.
>
> parse uses the directory when the link is printed out.
... but not when the file is opened. That's the problem.
>> you what file and why. Including the file name and $! would make this bug
>> easier to find.
>
> yes, this is my first draft and I haven't really worked in the error
> checking routine, but I will....
The error checking isn't something to pretty up later in the process - it's
there to help you find your bugs. This bug would have been obvious to you,
if the error message had included the full file name and $!.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Fri, 30 Apr 2004 12:06:43 -0800
From: "Robin" <webmaster @ infusedlight . net>
Subject: Re: search.pl
Message-Id: <c6ucl0$c79$1@reader2.nmix.net>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:c6u86d$g0gqj$1@ID-184292.news.uni-berlin.de...
> Robin wrote:
> > Sherm Pendley wrote:
> >> You should be using more helpful error messages. The above tells
> >> you nothing more than that a file failed to open - it would be
> >> better if it also told you what file and why. Including the file
> >> name and $! would make this bug easier to find.
> >
> > yes, this is my first draft and I haven't really worked in the
> > error checking routine, but I will....
>
> It's rude IMO to post a "first draft" of script and ask for criticism,
> since it unnecessarily takes up people's time.
ok, point taken.
------------------------------
Date: Fri, 30 Apr 2004 22:33:25 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: search.pl
Message-Id: <c6udho$g51qe$1@ID-184292.news.uni-berlin.de>
Robin wrote:
> Gunnar Hjalmarsson wrote:
>> It's rude IMO to post a "first draft" of script and ask for
>> criticism, since it unnecessarily takes up people's time.
>
> ok, point taken.
Really? And 17 minutes later you post a new script with shortcomings
that you say you are well aware of...
Stop it!!
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 30 Apr 2004 11:23:54 -0700
From: google@milbaugh.com (GreenLight)
Subject: Re: tunneling the richest cookies
Message-Id: <c4b60ce1.0404301023.6681b752@posting.google.com>
Stefano <vstefanoxx.bogacussu@tiscali.it> wrote in message news:<Xns94DBAB805FFF4vstefanoxx@195.130.225.75>...
> [snip]
I would rather EAT some rich cookies, not tunnel them 8^)
------------------------------
Date: Fri, 30 Apr 2004 18:55:03 +0000 (UTC)
From: J Krugman <jkrugman@yahbitoo.com>
Subject: use constant and BEGIN don't mix?
Message-Id: <c6u7e7$es9$1@reader2.panix.com>
If I try
my %x;
BEGIN {
%x = %{ do '/path/to/some/file' };
}
...where the file '/path/to/some/file' consists of the string
"+{ A => 1}\n", then everything is fine, but if instead I do
my %x;
BEGIN {
use constant DO_FILE => '/path/to/some/file';
%x = %{ do DO_FILE };
}
...I get an error ("Can't use an undefined value as a HASH reference").
(I get this error whether I place the "use constant" statement
inside or before the BEGIN block.)
Is there no way to perform a do operation in a BEGIN block using
a constant? Can someone explain to me, please, what's going on?
(Yes, I did read perlmod; it didn't help me with this one.)
Many thanks!
jill
--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.
------------------------------
Date: Fri, 30 Apr 2004 19:23:17 +0000 (UTC)
From: J Krugman <jkrugman@yahbitoo.com>
Subject: Re: use constant and BEGIN don't mix?
Message-Id: <c6u934$feb$1@reader2.panix.com>
In <c6u7e7$es9$1@reader2.panix.com> J Krugman <jkrugman@yahbitoo.com> writes:
>If I try
> my %x;
> BEGIN {
> %x = %{ do '/path/to/some/file' };
> }
>...where the file '/path/to/some/file' consists of the string
>"+{ A => 1}\n", then everything is fine, but if instead I do
> my %x;
> BEGIN {
> use constant DO_FILE => '/path/to/some/file';
> %x = %{ do DO_FILE };
> }
Sorry, I omitted an important line ("use strict;") in the snippets
above. I should have written:
If I try
use strict;
my %x;
BEGIN {
%x = %{ do '/path/to/some/file' };
}
...where the file '/path/to/some/file' consists of the string
"+{ A => 1}\n", then everything is fine, but if instead I do
use strict;
my %x;
BEGIN {
use constant DO_FILE => '/path/to/some/file';
%x = %{ do DO_FILE };
}
...I get an error ("Can't use an undefined value as a HASH reference").
(I get this error whether I place the "use constant" statement
inside or before the BEGIN block.)
>Is there no way to perform a do operation in a BEGIN block using
>a constant? Can someone explain to me, please, what's going on?
>(Yes, I did read perlmod; it didn't help me with this one.)
>Many thanks!
>jill
--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.
------------------------------
Date: Fri, 30 Apr 2004 12:50:37 -0700
From: Steven Kuo <skuo@mtwhitney.nsc.com>
Subject: Re: use constant and BEGIN don't mix?
Message-Id: <Pine.GSO.4.21.0404301234540.19868-100000@mtwhitney.nsc.com>
On Fri, 30 Apr 2004, J Krugman wrote:
>
> If I try
>
> my %x;
> BEGIN {
> %x = %{ do '/path/to/some/file' };
> }
>
> ...where the file '/path/to/some/file' consists of the string
> "+{ A => 1}\n", then everything is fine, but if instead I do
>
> my %x;
> BEGIN {
> use constant DO_FILE => '/path/to/some/file';
> %x = %{ do DO_FILE };
> }
>
> ...I get an error ("Can't use an undefined value as a HASH reference").
> (I get this error whether I place the "use constant" statement
> inside or before the BEGIN block.)
>
> Is there no way to perform a do operation in a BEGIN block using
> a constant? Can someone explain to me, please, what's going on?
> (Yes, I did read perlmod; it didn't help me with this one.)
The problem is unrelated to the BEGIN block.
You can force the context to a subroutine call (you'll have to study
constant.pm to see why):
use strict;
use warnings;
my %x;
BEGIN {
use constant DOFILE => '/path/to/file';
%x = %{ do +DOFILE() };
}
$\ = "\n";
$, = " ";
print keys %x, values %x;
print "My do file is", DOFILE;
Though I have to ask: why use such an awkward method to define a
hash?
--
Hope this helps,
Steven
------------------------------
Date: Fri, 30 Apr 2004 10:04:50 -0800
From: "Robin" <webmaster @ infusedlight . net>
Subject: Re: WHAT IS THE POINT OF FORMMAIL ?
Message-Id: <c6u4gn$677$1@reader2.nmix.net>
"Nomen Nescio" <nobody@dizum.com> wrote in message
news:fc48601f9736c2fbd4ac804219d29e33@dizum.com...
> WHY ? No one needs this outdated crap anymore.
>
> 3 lines of PHP can do what shitty formmail does and better and more
safely.
>
> Formmail is the spammers choice, formmail is so controversial that many
hosts
> ban it outright.
>
> Clunky, outdated shit and if you have an old version it is full of holes
and
> exploits for hackers and spammers.
>
> Fuck of formmail you suck. Totally pointless useless shit. go away
formmail
I should plug you into a formmail script and see what kinda spam I can send.
jk, but seriously, can't you post to a php group?
-Robin
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 6495
***************************************
