[18804] in Perl-Users-Digest
Perl-Users Digest, Issue: 972 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 23 21:05:48 2001
Date: Wed, 23 May 2001 18:05:14 -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: <990666314-v10-i972@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 23 May 2001 Volume: 10 Number: 972
Today's topics:
Re: "listen" to a file <buggs@geekmail.de>
[OT] Re: module for combinatorics? (partitions etc) <mischief@velma.motion.net>
Re: [Solved!] How to match the password created in Linu (Joseph Chen)
Re: ActivePerl <bart.lateur@skynet.be>
Re: Array slice: how about the remainder? <mischief@velma.motion.net>
Re: Array slice: how about the remainder? <godzilla@stomp.stomp.tokyo>
Re: bitwise <bart.lateur@skynet.be>
Re: Design pattern for a generic functions dispatcher <buggs@geekmail.de>
easiest way to find no. of keys in a hash <smrtalec@nospam.earthlink.net>
Re: easiest way to find no. of keys in a hash <tony_curtis32@yahoo.com>
Re: Existing Script To Add Time <ausit@bigpond.net.au>
Re: Handling JPEGs without modules (Honza Pazdziora)
Re: Handling JPEGs without modules <mischief@velma.motion.net>
Re: help: String Match <webmaster@bestwebscripts.com>
Re: help: String Match <joelh@juniper.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 24 May 2001 01:19:43 +0200
From: buggs <buggs@geekmail.de>
Subject: Re: "listen" to a file
Message-Id: <9ehgis$24l$06$1@news.t-online.com>
Peter Søgaard wrote:
> Hi,
>
> Is it possible to have perl "listen to" a certain file, and then trigger
> some event when this file is updated( i.e. overwritten ).
> I can probably use sleep x seconds and then check the file status once in
> a while and decide whether the file has been updated since last time i
> checked...but is there a more correct way of doing this?...if so, how? :)
>
>
>
you could use a "named Pipe" aka "FIFO",
if you either can mv() the file or make the other programm
write to another location instead.
Say you have "my.log".
you make a FIFO called myfifo.log.
The programm "behind" the myfifo.log Pipe
could then write to my.log and trigger your action.
Buggs
------------------------------
Date: Wed, 23 May 2001 23:30:31 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: [OT] Re: module for combinatorics? (partitions etc)
Message-Id: <tgoi0nccno0u25@corp.supernews.com>
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> In a case like this, where a recursive solution has an advantage in
> clarity (never mind that I got it wrong all the same :), I'd consider
> the iterative variant an optional optimization.
> It is strange to note that one of the most popular examples for
> recursion is the computation of factorials, where the recursive
> approach has no advantage at all.
Another is the Fibonacci series. The Language Shootout[1], for one,
uses a recursive method specifically to show the subroutine call
overhead and such of different languages. An iterative approach
in Perl, however, beats the recursive method coded in any of the
languages used on the site. Of course, if you have the Golden Number
(Phi) handy, who needs to iterate or recur?
[1] http://www.bagley.org/~doug/shootout/
Chris
--
Product shown enlarged to make you think you're getting more.
------------------------------
Date: 23 May 2001 16:58:06 -0700
From: yen_hung@yahoo.com (Joseph Chen)
Subject: Re: [Solved!] How to match the password created in Linux shadow suite?
Message-Id: <bf927196.0105231558.2b9e36e8@posting.google.com>
Please ignore my previous reply. It works perfectly.
Thanks,
Joseph
"Kevin Hancock" <khan@arcom.com.au> wrote in message news:<3b0bbe8d@kastagir.senet.com.au>...
> sub VerifyPass{
> my($passwd, $user)=@_;
> open(SHAD, $MYshad) or dienice (" Failed to open $MYshad\n\n");
> while( <SHAD> ){
> @data=split(/:/, $_);
> if ( $data[0] eq $user ){
> if ($data[1] eq crypt($passwd , $data[1])){
> close(SHAD);
> return 1;
> }
> }
> }
> close(SHAD);
> return 0;
> }
>
> This is what I do. I do not like it as it traverses the entire length of
> /etc/shadow each time especially if a miss.
>
> I am new so if my code sucks pls feel free to pick it to pieces. It does
> work though copied direct from my code.
>
>
> Joseph Chen wrote in message ...
> >The reply has a misunderstanding about the statement of the problem.
> >Whithout the Linux shadow suite, a common practice allows the password
> >a user types in to be encryped and compared against the system password
> >of the user in order to verify the access of the user. For a password
> >read from the user, e.g., $passwd_read, we can do the following in
> >perl to verify his/her access to the system.
> >
> >$salt = substr($passwd_read,0,2);
> >$passwd_read_and_encrypted = crypt($passwd_read,$salt);
> >if ($passwd_read_and_encrypted eq $user_passwd_encrypted_from_system) {
> > the user has access
> >} else {
> the usr has no access
> >}
> >
> >Without using the shadow suite, we can get
> $user_passwd_encrypted_from_system
> >from /etc/passwd file. It does not require a 'root' access privilege to
> >read this file and the above codes work!
> >
> >With the shadow suite, all user passwords in /etc/passwd are moved
> >to /etc/shadow and the passwords in /ect/password are replaced by '*'.
> >
> >To solve this password moving issue, I can read the user password
> >$user_passwd_encrypted_from_system from /etc/shadow instead of
> >/ect/passwd. But, the major problem I could not solve is that
> >the encrpyted password in /ect/shadow is longer than the password
> >encrypted in /etc/passwd. They have different lengths. This is
> >why my comparion if-statement in the above codes fails, even if
> >the $passwd_read is the same as the password of the user before
> >the password is encrypted by the shadow suite.
> >
> >Is it because the shadow suite uses a different encrypton method?
> >And, how do I fix this problem using perl? Any help is appreciated.
> >
> >
> >Joseph Chen
> >
> >P.S. I have root access to the machines I work on. So, please do not
> >raise the root access issue anymore.
> >
> >abigail@foad.org (Abigail) wrote in message
> news:<slrn9gcg31.sk5.abigail@tsathoggua.rlyeh.net>...
> >> Joseph Chen (yen_hung@yahoo.com) wrote on MMDCCCXVIII September MCMXCIII
> >> in <URL:news:bf927196.0105182003.1e825283@posting.google.com>:
> >> "" Dear Perl Users,
> >> ""
> >> "" I move a CGI program from an IBM machine to a Linux machine.
> >> "" In the IBM machine, the program allows users to enter their
> >> "" login password and uses the password to match the one in
> >> "" /etc/passwd file. It works ok. But, after I move the program
> >> "" to the Linux machine. The password comparison fails.
> >>
> >>
> >> Due to shadow passwords. This is a feature. It avoids security problems
> >> like programs from other users asking for passwords and checking them.
> >> A quick way to collect passwords from other people on the system.
> >>
> >> You are not experiencing "a problem", just like a bank robber isn't
> >> experiencing "a problem" when facing the vault. You are both encountering
> >> a safety device designed to keep you out.
> >>
> >>
> >> Unless you are root, you have no business of collecting peoples
> passwords.
> >> And when you are, you shouldn't have to ask how to do it.
> >>
> >>
> >>
> >> Abigail
------------------------------
Date: Wed, 23 May 2001 22:21:33 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: ActivePerl
Message-Id: <l1eogt8efsjeasrm5d5h5c1sbn1pc9trr3@4ax.com>
Kay Schulz wrote:
>unter UNIX sage ich
>#!/bin/perl
>
>wie mache ich das unter Windows 2000?
Just
#!perl
usually will do.
--
Bart.
------------------------------
Date: Wed, 23 May 2001 22:45:48 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Array slice: how about the remainder?
Message-Id: <tgofcsn5pdin53@corp.supernews.com>
Since the OP asked for a clear way to solve his problem and
the thread switched to discussion of efficient ways to solve
it, some of the code posted was intended to be clear but not
necessarily the most efficient. Therefore, I'm sure some of
the benchmarks below reflect this. A low score on this
benchmark, therefore, shouldn't be taken as a comment on the
abilities of the programmer who posted the code.
John Lin <johnlin@chttl.com.tw> wrote:
> "Chris Stith" wrote
>> my @stay_home = ();
>> my %chosen = ();
>> keys(%chosen) = @chosen;
>> for( @array ) {
>> unless( exists( $chosen{$_} ) ) {
>> push @stay_home, $_;
>> }
>> }
>> I'd imagine it would be more efficient to write the thing as a hash
>> initially. ;-)
> Since all indexes are integers, I think using an array is more efficient
> than hash. (No need to stringify. Takes up less space.)
> my @array = 0..70;
> my @chosen = (0,3,5,7,21,35,63,66,68);
> my @seen; @seen[@chosen] = ();
> my @stay_home = @array[grep {!exists $seen[$_]} 0..$#array];
> Actually, Anno has proposed a "vec" version in other branch
> of this thread which just uses a scalar.
I've read the full thread including updates, as I nearly always do
once I've decided the thread is worth my time.
### ###
### ###
### Post Summary ###
### ###
### ###
Since this post is quite long and contains a bunch of statistics,
I'll say a couple of things here in case you want to move on to
the next post.
There are actually two inputs to this problem. Some code posted
was optimized for one input, and some for the other. Some was
well balanced. In fact, some code blew away the average at one
extreme and crawled at the other while some was consistently
found in the middle range.
My code is actually twofold: an implementation which I use as
a baseline (called two_loops) and one that's about mediocre
the entire time (hash).
Joe S.'s code came out on top every time but one, and often by
a good margin. It is also one of the clearer examples and I think
the most concise. It does, however, give me warnings and when
printing the array, it shows where the elements would be. I
therefore will be referring below to a few "fastest" speeds
which appear to be slower than Joe's code.
Ren's code fixes this, but using grep slows it drastically in many
cases. In other cases, such as thorough coverage of the chosen
set over the original set, it is the fastest. It is still in
a good place for smaller input sets even with sparse coverage.
It slows down quite a bit with sparse coverage at large set sizes.
MJD's code is the fastest at times, those times being when there
is sparse coverage. It is the slowest under dense coverage.
Anno's also does best in sparse coverage.
I don't think nobull was interested in benchmarking -- only in
giving a clear example. I think we can be almost sure of this,
because he posted two versions -- his first one, which I use
because it gives me no warnings, and his second one, which
anecdotally seemed to be faster but gave me warnings. He said
seemd to prefer his second one in his post.
John and Kira were very consistently near the top. They even
played a little leapfrog with one another. Kira, though,
maintained the highest speeds in the group on a couple of the
tests with the largest data set.
The moral of the post is to care about the sizes of all input
sets, not just the one you find most important at first glance.
The moral of the thread is TMTOWTDI. ;-)
### ###
### now back to the post... ###
### ###
At 10,000 total data items and 150 chosen items, yours is only
nominally faster than mine using a hash, even changing from an
array to a hash in the tested part.
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 10 CPU seconds...
anno: 11 wallclock secs @ 23.08/s (n=244)
hash: 11 wallclock secs @ 15.79/s (n=166)
joe_s: 11 wallclock secs @ 34.42/s (n=359)
john_lin: 59 wallclock secs @ 16.81/s (n=178)
kira: 13 wallclock secs @ 18.89/s (n=198)
mjd: 11 wallclock secs @ 32.09/s (n=336)
nobull: 10 wallclock secs @ 5.61/s (n=61)
ren: 11 wallclock secs @ 10.21/s (n=106)
two_loops: 10 wallclock secs @ 8.64/s (n=91)
These scores are for 10,000 data elements and 150 chosen, using
Perl 5.6.0 on RH Linux 6.2 for Intel. I ran it three times and
picked the median time for each of the above. Here's what my own
naive mark-and-compare method using vec looked like (it was
called two_loops in the benchmark):
sub two_loops {
my @stay_home = ();
my $vec = 0;
for(@chosen) {
vec( $vec, $_, 1) = 1;
}
for(my $i = 0; $i < @array; $i++) {
unless( vec($vec, $i, 1) ) {
push @stay_home, $array[$i];
}
}
}
I used this as a base from which to compare, with no real
concern for how it benchmarked. I was a bit surprised at how
poorly it did, though.
The rest of the data is gathered the same way as the above...
each method is cut-n-pasted its median time from three runs
of the program. Runs with 20,000 data items switch to 30
seconds CPU time instead of 10.
Here are the benchmarks for 1,000 data items 150 of which are
selected:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 10 CPU seconds...
anno: 11 wallclock secs @ 180.15/s (n=1915)
hash: 10 wallclock secs @ 170.85/s (n=1811)
joe_s: 10 wallclock secs @ 458.92/s (n=4837)
john_lin: 10 wallclock secs @ 205.23/s (n=2157)
kira: 10 wallclock secs @ 214.83/s (n=2260)
mjd: 11 wallclock secs @ 265.00/s (n=2809)
nobull: 11 wallclock secs @ 87.71/s (n=921)
ren: 11 wallclock secs @ 155.41/s (n=1638)
two_loops: 11 wallclock secs @ 93.42/s (n=979)
Here's for 200 data items with 50 chosen:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 10 CPU seconds...
anno: 11 wallclock secs @ 942.64/s (n=9860)
hash: 11 wallclock secs @ 829.43/s (n=8792)
joe_s: 10 wallclock secs @ 2317.91/s (n=24199)
john_lin: 11 wallclock secs @ 1046.67/s (n=10990)
kira: 11 wallclock secs @ 1086.69/s (n=11345)
mjd: 11 wallclock secs @ 1193.92/s (n=12560)
nobull: 11 wallclock secs @ 474.10/s (n=5016)
ren: 10 wallclock secs @ 867.34/s (n=9081)
two_loops: 10 wallclock secs @ 468.16/s (n=4925)
Here's with 20,000 data elements, 11,000 of which are chosen:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 31 wallclock secs @ 2.33/s (n=73)
hash: 32 wallclock secs @ 7.39/s (n=233)
joe_s: 32 wallclock secs @ 13.48/s (n=423)
john_lin: 31 wallclock secs @ 9.31/s (n=293)
kira: 80 wallclock secs @ 9.63/s (n=312)
mjd: 31 wallclock secs @ 4.33/s (n=135)
nobull: 34 wallclock secs @ 3.43/s (n=115)
ren: 32 wallclock secs @ 6.88/s (n=215)
two_loops: 32 wallclock secs @ 4.69/s (n=148)
Here's with 20,000 data elements, only 1,000 of which are chosen:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 32 wallclock secs @ 7.58/s (n=240)
hash: 31 wallclock secs @ 7.48/s (n=236)
joe_s: 31 wallclock secs @ 14.15/s (n=441)
john_lin: 31 wallclock secs @ 7.37/s (n=232)
kira: 31 wallclock secs @ 8.33/s (n=263)
mjd: 31 wallclock secs @ 8.79/s (n=278)
nobull: 80 wallclock secs @ 2.42/s (n=82)
ren: 31 wallclock secs @ 4.13/s (n=130)
two_loops: 31 wallclock secs @ 3.97/s (n=125)
Here's with 20,000 elements, 19,000 of which are slected:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 31 wallclock secs @ 2.27/s (n=71)
hash: 80 wallclock secs @ 7.14/s (n=225)
joe_s: 32 wallclock secs @ 12.24/s (n=386)
john_lin: 33 wallclock secs @ 10.79/s (n=342)
kira: 31 wallclock secs @ 11.04/s (n=346)
Perhaps invalid... psychotic data given...
mjd: 31 wallclock secs @ 0.68/s (n=21)
nobull: 84 wallclock secs @ 4.21/s (n=150)
ren: 32 wallclock secs @ 10.08/s (n=320)
two_loops: 31 wallclock secs @ 5.29/s (n=167)
About the "Perhaps invalid... psychotic data given..." line:
This is a tiny little patch I submitted to p5p to keep the
Benchmark module from dying on a divide-by-zero when the code
being benchmarked couldn't handle the data load in the assigned
time. Check the p5p archives for a complete story. It applies
to the line immediately following the message.
Here's something closer to the scenario the OP posted. There
are 100 data elements. First, I ran with none selected, then
one, then 25, then 50, then 75, then 99, then all 100.
with zero:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 32 wallclock secs @ 2725.34/s (n=86039)
hash: 32 wallclock secs @ 2216.98/s (n=69968)
joe_s: 89 wallclock secs @ 7843.69/s (n=258136)
john_lin: 32 wallclock secs @ 2325.10/s (n=71706)
kira: 32 wallclock secs @ 2471.73/s (n=77909)
mjd: 30 wallclock secs @ 7242.97/s (n=228226)
nobull: 32 wallclock secs @ 920.58/s (n=28814)
ren: 32 wallclock secs @ 2186.27/s (n=69130)
two_loops: 31 wallclock secs @ 1029.78/s (n=32366)
with one:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 32 wallclock secs @ 2064.29/s (n=64922)
hash: 32 wallclock secs @ 2220.18/s (n=70180)
joe_s: 32 wallclock secs @ 8046.30/s (n=254585)
john_lin: 32 wallclock secs @ 2308.68/s (n=72608)
kira: 81 wallclock secs @ 2411.91/s (n=76964)
mjd: 32 wallclock secs @ 6760.46/s (n=211670)
nobull: 31 wallclock secs @ 916.96/s (n=28985)
ren: 31 wallclock secs @ 2186.64/s (n=68923)
two_loops: 31 wallclock secs @ 1001.52/s (n=31688)
with 25:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 30 wallclock secs @ 1697.25/s (n=52428)
hash: 32 wallclock secs @ 1614.85/s (n=50884)
joe_s: 31 wallclock secs @ 4642.50/s (n=146146)
john_lin: 30 wallclock secs @ 2027.97/s (n=63942)
kira: 80 wallclock secs @ 2121.86/s (n=66987)
mjd: 32 wallclock secs @ 2423.30/s (n=76043)
nobull: 32 wallclock secs @ 949.40/s (n=29963)
ren: 32 wallclock secs @ 1730.58/s (n=54323)
two_loops: 31 wallclock secs @ 920.97/s (n=29158)
with 50:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 30 wallclock secs @ 1494.29/s (n=47130)
hash: 32 wallclock secs @ 1605.87/s (n=50874)
joe_s: 31 wallclock secs @ 4546.63/s (n=142537)
john_lin: 32 wallclock secs @ 2178.51/s (n=68514)
kira: 89 wallclock secs @ 2150.88/s (n=69968)
mjd: 33 wallclock secs @ 1655.58/s (n=51472)
nobull: 32 wallclock secs @ 1075.10/s (n=33855)
ren: 32 wallclock secs @ 2111.83/s (n=66776)
two_loops: 36 wallclock secs @ 944.72/s (n=30335)
with 75:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 29 wallclock secs @ 1362.89/s (n=41091)
hash: 32 wallclock secs @ 1590.41/s (n=50082)
joe_s: 31 wallclock secs @ 4281.52/s (n=132299)
john_lin: 30 wallclock secs @ 2303.77/s (n=72154)
kira: 32 wallclock secs @ 2310.15/s (n=72608)
mjd: 32 wallclock secs @ 1257.66/s (n=39566)
nobull: 80 wallclock secs @ 1211.10/s (n=38949)
ren: 32 wallclock secs @ 2540.63/s (n=76473)
two_loops: 31 wallclock secs @ 988.02/s (n=30767)
with 99:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 32 wallclock secs @ 1244.55/s (n=39079)
hash: 83 wallclock secs @ 1627.90/s (n=49602)
joe_s: 33 wallclock secs @ 4150.44/s (n=131071)
john_lin: 32 wallclock secs @ 2487.86/s (n=77671)
kira: 31 wallclock secs @ 2436.71/s (n=76732)
mjd: 30 wallclock secs @ 1074.35/s (n=33756)
nobull: 31 wallclock secs @ 1479.53/s (n=46398)
ren: 32 wallclock secs @ 3492.89/s (n=109607)
two_loops: 81 wallclock secs @ 1025.57/s (n=30767)
...and the final benchmark of the post, with 100% coverage:
Benchmark: running anno, hash, joe_s, john_lin, kira, mjd, nobull,
ren, two_loops, each for at least 30 CPU seconds...
anno: 32 wallclock secs @ 1279.27/s (n=40182)
hash: 76 wallclock secs @ 1603.49/s (n=51007)
joe_s: 31 wallclock secs @ 4257.10/s (n=128224)
john_lin: 31 wallclock secs @ 2587.50/s (n=81765)
kira: 31 wallclock secs @ 2479.60/s (n=77909)
mjd: 32 wallclock secs @ 1073.48/s (n=33804)
nobull: 33 wallclock secs @ 1543.72/s (n=48689)
ren: 32 wallclock secs @ 6008.33/s (n=190344)
two_loops: 77 wallclock secs @ 1051.59/s (n=33388)
--
You can never entirely stop being what you once were. That's
why it's important to be the right person today, and not put
it off till tomorrow. -- Larry Wall, 3rd State of the Onion
------------------------------
Date: Wed, 23 May 2001 16:45:07 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Array slice: how about the remainder?
Message-Id: <3B0C4B83.C53DA1C5@stomp.stomp.tokyo>
Chris Stith wrote:
(lots of snippage)
> Since the OP asked for a clear way to solve his problem and
> the thread switched to discussion of efficient ways to solve
> it, some of the code posted was intended to be clear but not
> necessarily the most efficient. Therefore, I'm sure some of
> the benchmarks below reflect this.
> Joe S.'s code came out on top every time but one, and often by
> a good margin. It is also one of the clearer examples and I think
> the most concise. It does, however, give me warnings and when
> printing the array, it shows where the elements would be. I
> therefore will be referring below to a few "fastest" speeds
> which appear to be slower than Joe's code.
Very entertaining!
I experienced difficulties in trying to develop a fair
control for Joe's code so all codes tested would be
subject to the same conditions. Clearly there are many
ways to remove those null elements from his array.
However, my method of changing his array to a string
then deleting multiple spaces, may not have been the
most fair control for his code; it slows his code down
an average of fifty percent. I thought of looping
and removal but decided this would be too slow. Other
methods, I wasn't sure. Nonetheless, his code does
very well indeed.
> The moral of the post is to care about the sizes of all input
> sets, not just the one you find most important at first glance.
Contrary to stereotyping of my gender, I say
size does matter.
* thinks about her boyfriend of twenty years *
Yes it does.
This was a fun thread which proves to be informative
for all holding interest in this topic.
Godzilla!
------------------------------
Date: Wed, 23 May 2001 22:20:37 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: bitwise
Message-Id: <uvdogt4mc7lcc28dhiop041kjk8lmh0o3r@4ax.com>
Randal L. Schwartz wrote:
>and yes, this will be a future Perl column. :) :)
Wow. Lots of inspiration today.
--
Bart.
------------------------------
Date: Thu, 24 May 2001 01:10:01 +0200
From: buggs <buggs@geekmail.de>
Subject: Re: Design pattern for a generic functions dispatcher
Message-Id: <9ehg0l$1hr$06$1@news.t-online.com>
Phouric Ung wrote:
--snip--
> #!perl.exe
>
> %ACTION_MAPS = (
> ACTION1 => MyModule::MyFunction,
> ...
> );
>
> $Action=$argv[0];
>
> # Various Processing
>
> # Call the desired function
> $module = ExtractModuleNameFromFullFunctionName($ACTION_MAPS{$Action});
> eval {
> use $module;
> &$ACTION_MAPS{$Action}();
> }
> die $@ if $@;
>
> --------------------------------------
>
> Should works but seems awkward, i was wondering if there
> are better things to do.
>
> Thanks in advance
>
> Phouric Ung
>
Looks good.
I'd leave it that way.
You may consider AUTOLOAD,
which is special sub getting called when
a sub you call isn't defined.
You may consider 'require' over 'use'.
Runtime / Compiletime import issue.
You may, for further optimization, consider
defining what your modules export by
making them @ISA Exporter ( inherite Exporter ).
Buggs
------------------------------
Date: Thu, 24 May 2001 00:02:33 GMT
From: "R" <smrtalec@nospam.earthlink.net>
Subject: easiest way to find no. of keys in a hash
Message-Id: <tcYO6.15120$9D5.1302415@newsread2.prod.itd.earthlink.net>
what is the easiest way to find the number of keys ( entries) in a hash ?
------------------------------
Date: 23 May 2001 19:04:36 -0500
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: easiest way to find no. of keys in a hash
Message-Id: <87wv77d33f.fsf@limey.hpcc.uh.edu>
>> On Thu, 24 May 2001 00:02:33 GMT,
>> "R" <smrtalec@nospam.earthlink.net> said:
> what is the easiest way to find the number of
> keys (entries) in a hash ?
^^^^
perldoc -f keys (not surprisingly)
hth
t
--
Just reach into these holes. I use a carrot.
------------------------------
Date: Wed, 23 May 2001 22:38:40 GMT
From: Raoul Callaghan <ausit@bigpond.net.au>
Subject: Re: Existing Script To Add Time
Message-Id: <B7327832.30B4%ausit@bigpond.net.au>
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B_3073538099_197910
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: 8bit
guys,
simply use this perl function...
use Date::Calc qw(:all);
eg: the code below adds one month to the current date:
$Dd=(Days_in_Month($year,$month));
($Add_year, $Add_month, $Add_day) = Add_Delta_Days($year, $month, $day,
$Dd);
And this one simply determines how many days between the two dates:
$Test_Period=Delta_Days($yyyy_st, $mm_st, $dd_st, $yyyy_fin, $mm_fin,
$dd_fin);
the mod also has time facilities that are virtually identical to the above
code....
the function is: Date-Calc-4.3.tar
do your typical, perl Makefile.PL, make, make test, make install etc....
and you can see what it¹s capable of here:
http://theoryx5.uwinnipeg.ca/CPAN/data/Date-Calc/Calc.html
I used this module to provide a ³relative² time feature for submitting
articles through html..
eg: the users wanted to make an article readable at the start of next month,
and expire one month later.
--B_3073538099_197910
Content-type: text/html; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Re: Existing Script To Add Time</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana">guys,<BR>
<BR>
simply use this perl function...<BR>
<BR>
use Date::Calc qw(:all);<BR>
<BR>
eg: the code below adds one month to the current date:<BR>
$Dd=3D(Days_in_Month($year,$month));<BR>
($Add_year, $Add_month, $Add_day) =3D Add_Delta_Days($year, $month, $day, $Dd=
);<BR>
<BR>
And this one simply determines how many days between the two dates:<BR>
$Test_Period=3DDelta_Days($yyyy_st, $mm_st, $dd_st, $yyyy_fin, $mm_fin, $dd_f=
in);<BR>
<BR>
the mod also has time facilities that are virtually identical to the above =
code....<BR>
<BR>
the function is: Date-Calc-4.3.tar<BR>
do your typical, perl Makefile.PL, make, make test, make install etc....<BR=
>
<BR>
and you can see what it’s capable of here: http://theoryx5.uwinnipeg.=
ca/CPAN/data/Date-Calc/Calc.html<BR>
<BR>
I used this module to provide a “relative” time feature for sub=
mitting articles through html..<BR>
<BR>
eg: the users wanted to make an article readable at the start of next month=
, and expire one month later.<BR>
</FONT>
</BODY>
</HTML>
--B_3073538099_197910--
------------------------------
Date: Wed, 23 May 2001 18:10:30 GMT
From: adelton@fi.muni.cz (Honza Pazdziora)
Subject: Re: Handling JPEGs without modules
Message-Id: <slrn9gnva4.3jhk.adelton@nemesis.fi.muni.cz>
On 22 May 2001 22:23:25 GMT, Eric Bohlman <ebohlman@omsdev.com> wrote:
>
> That will only work if your machine has the exact same architecture and OS
> as the Web host's machine, and even then only if you have the same
> compiler that the host's machine's perl was compiled with. "Solutions"
> that depend on lots of coincidences tend not to work very well.
But then, still could work better than trying to find JPEG handling
(reading/writing) code in pure Perl. The OP obviously didn't explore
the possibilities of compiling the modules on the target platform/
/installing the compiled modules. Which leaves us guessing the
coincidences, of course.
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, mod_perl, DBI, Oracle, auth. WWW servers, XML/XSL, ...
Petition for a Software Patent Free Europe http://petition.eurolinux.org
------------------------------------------------------------------------
------------------------------
Date: Wed, 23 May 2001 22:58:24 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: Handling JPEGs without modules
Message-Id: <tgog4gmb3k0d42@corp.supernews.com>
Eli the Bearded <elijah@workspot.net> wrote:
> In comp.lang.perl.misc, Chris Stith <mischief@velma.motion.net> wrote:
[snip]
>> will be more than willing to tell you their hardware, OS, and
>> compiler specs if you ask.
> To make this more on-topic for clpm, you can often get perl to
> tell you: 'perl -V'. Or for a CGI:
> #!/path/to/perl -Tw
> use Config qw( myconfig );
> print "Content-Type: text/plain\n\n";
> print myconfig;
> __END__
Excellent point.
>> So, if you know that your hardware, compiler, and OS are the same
>> as where your website is hosted, it's not that hard to setup the
>> same thing at your own office or at home (unless of course you're
> This can be a fair amount of work. It gets harder if you are a
> site designer/coder working for multiple clients who don't all
> host with you.
True, this does complicate things. It also complicates the matter
in the next couple of paragraphs. Life is a bumpy road. One can
work to smooth out some of the bumps, though, instead of reinventing
the road _and_ the wheel.
>> a small shop and your site is hosted on an SGI box or a Sun
>> UltraSparc or somesuch). Since there are plenty of hosting
>> companies which offer PC or UltraSparc hosting on Solaris, BSD,
>> or Linux, one should be able to find a host which will have a setup
>> comparable to one you can build at home.
> If changing hosting companies is an option, one can just change to
> one that will install modules for you.
This is an option, of course. There seem to be, from the amount
of similar traffic in the comp.lang.perl.* groups, many hosting
companies which are worthwhile to the posters for other reasons
which do not install modules.
>> If you simply can't have
>> a PC-based box with NetBSD, OpenBSD, FreeBSD, or some form of Linux
>> at home, then you may want to think about the state of your career
>> as an IT professional.
> "If you can't duplicate what your hosting site has, you must suck."
> Sorry, but I just find that extremely naive.
That's not what I was saying. I was saying that if your hosting
company has a hardware and software combination which is cheap
and easy to duplicate, a professional in a computer-related
field should be able to duplicate it. Dell sells PCs preloaded
with Linux, for instance, or you can load a free copy on a 386.
Notice I did specify what hardware and software I meant in that
paragraph. I didn't say everyone should buy an IBM S/390 for
home. ;-)
>> If one can't have SSH access, can't run make from CGI, and can't
>> get one's hands on the same setup as the hosting company, perhaps
>> it's time to look for a different hosting company, or to colocate
>> your own box in a customer-managed colocation arrangement.
> That's more reasonable.
I still fail to see why it's not reasonable to expect someone
to be able to get Linux or Solaris x86 at home. ;-)
> You left out: "Can't learn to accept what your hosting site does
> have".
That's another excellent point. However, I think the OP has accepted
what they have, and is ready to work around it in a rather ugly way.
> thinks the OP should recosider the necessity of 'jpeg' support
That's a possibility, but perhaps the OP already has and found the
jpeg format is still very important to the needs of the project.
Chris
--
Where there's a will, there's a lawyer.
------------------------------
Date: Thu, 24 May 2001 02:36:01 +0400
From: Serge <webmaster@bestwebscripts.com>
Subject: Re: help: String Match
Message-Id: <3B0C3B51.34AB8F52@bestwebscripts.com>
Hello,
Try following regexp:
s/user\@mailserver1.com/\Quser\@mailserver2\E/g;
u518615722@spawnkill.ip-mobilphone.net wrote:
>
> we need to change a lot of email address
> in our files, the target line is like this
> string=user\@mailserver1.com
>
> I issued
> perl -pi.bak -e "s/user\\\@mailserver1.com/
> user\@mailserver2/g" `find ----'
>
> and
>
> perl -pi.bak -e "s/user\\@mailserver1.com/
> user\@mailserver2/g" `find ----'
>
> and
> perl -pi.bak -e "s/user\@mailserver1.com/
> user\@mailserver2/g" `find ----'
>
> None of them seems to work the trick.
>
> What is wrong with my perl command?
>
> thanks
>
>
>
> --
> Sent by dbadba62 from hotmail part of com
> This is a spam protected message. Please answer with reference header.
> Posted via http://www.usenet-replayer.com/cgi/content/new
--
CGI scripts and programming
http://bestwebscripts.com
------------------------------
Date: 23 May 2001 15:35:00 -0700
From: Joel Ray Holveck <joelh@juniper.net>
Subject: Re: help: String Match
Message-Id: <y7cr8xf66ej.fsf@sindri.juniper.net>
> we need to change a lot of email address
> in our files, the target line is like this
> string=user\@mailserver1.com
It'd be better if you would give an example of "before" and "after"
lines. With what you've given, I'm not sure what you're trying to do.
> I issued
> perl -pi.bak -e "s/user\\\@mailserver1.com/
> user\@mailserver2/g" `find ----'
> and
<snip>
> None of them seems to work the trick.
> What is wrong with my perl command?
Beats me; I don't know what you're trying to do with Perl,
particularly with that embedded newline. But your shell command needs
to match backticks to backticks, so use `find ----` (assuming that
you're using ---- to stand for a valid find argument list). That may
be too long for your command line; you can read up on xargs if that's
the case.
Cheers,
joelh
------------------------------
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 972
**************************************
