[18990] in Perl-Users-Digest
Perl-Users Digest, Issue: 1185 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 25 03:05:37 2001
Date: Mon, 25 Jun 2001 00:05:10 -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: <993452709-v10-i1185@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 25 Jun 2001 Volume: 10 Number: 1185
Today's topics:
Re: A question on some basic things (Mark Jason Dominus)
Checking for duplicates before appending to file <davsoming@lineone.net>
Re: Checking for duplicates before appending to file <mbudash@sonic.net>
Re: does DB_File work under win32 platforms? <bwalton@rochester.rr.com>
Re: fastest way to count lines in a bunch of files. <monty@primenet.com>
Re: fastest way to count lines in a bunch of files. <time4tea@monmouth.com>
Re: fastest way to count lines in a bunch of files. <prariedawn @hotmail.com>
Re: Filehandles and close. (Mark Jason Dominus)
finding a file in a directory and reading it (Nina)
Re: finding a file in a directory and reading it <bop@mypad.com>
Re: how can i compile a perl program (Tony L. Svanstrom)
Re: how can i compile a perl program <links@fluxcenter.com>
How can I get rid of lines with garbage in a large fil <rig01@yahoo.com>
Re: How to automatically ANNOUNCE my module ?? With a s (isterin)
I have a large file, with garbage inside ; How can I ge <rig01@yahoo.com>
I have a large file, with garbage inside ; How can I ge <rig01@yahoo.com>
Re: I have a large file, with garbage inside ; How can <monty@primenet.com>
Re: loading enviroment variables <boa@aaanet.ru>
Re: passing variables the 'right' way (Mark Jason Dominus)
Re: passing variables the 'right' way <uri@sysarch.com>
Re: Perl *is* strongly typed (was Re: Perl description) <newspost@coppit.org>
Re: Perl Project (David H. Adler)
Re: Problem reading large files (dumb question?) <trw@uakron.edu>
Re: Requires or All One File (Eric Bohlman)
Re: simple reference question <mjd@plover.com>
Re: Six degrees of separation (Mark Jason Dominus)
Why automatic translation to C will not make Perl progr (Mark Jason Dominus)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 25 Jun 2001 06:28:03 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: A question on some basic things
Message-Id: <3b36d9f2.5ebd$89@news.op.net>
In article <3B2D71A5.8000202@csis.hku.hk>,
Bernard Chan <khchan2@csis.hku.hk> wrote:
>I would like to know why it is incorrect to say that
>execution of compiled programs is often faster than
>that of interpreted programs.
Bernard, that is a good question. It's hard to know just what Tom
Christiansen might have meant, without seeing the original context.
If you can remind me of the URL of the page in which Tom said that, I
will take a look and try to explain what he was thinking of.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: Mon, 25 Jun 2001 07:22:47 +0100
From: "David Soming" <davsoming@lineone.net>
Subject: Checking for duplicates before appending to file
Message-Id: <tjdlpk38ueon8d@corp.supernews.co.uk>
Hi,
I would like to check for duplicates in my database before appending:
open (EMAILS, ">>address.txt");
flock(EMAILS, 2);
print EMAILS "$email\n";
flock(EMAILS, 8);
close (EMAILS);
This is a whole new ball game and "struggling" to say the least. I would
appreciate it if anyone can help me incorporate some code to the existing
above.
I have this tangled mess...
open(EMAILS,"address.txt");
@address=<EMAILS>;
close(EMAILS);
$add = grep{ /$email{'address'}/i } @email;
if (@add) {
$errormessage = "The address you entered, <B>$email{'address'}</B> is
already in our mailing list";
}
exit;
But then- Im only learning!
Be kind :-)
Thanks.
--
David Soming
'Just a head-banger- doing what I do best'
______________
------------------------------
Date: Sun, 24 Jun 2001 23:52:33 -0700
From: Michael Budash <mbudash@sonic.net>
Subject: Re: Checking for duplicates before appending to file
Message-Id: <mbudash-6F19EC.23523324062001@news.pacbell.net>
In article <tjdlpk38ueon8d@corp.supernews.co.uk>, "David Soming"
<davsoming@lineone.net> wrote:
> Hi,
> I would like to check for duplicates in my database before appending:
> open (EMAILS, ">>address.txt");
> flock(EMAILS, 2);
> print EMAILS "$email\n";
> flock(EMAILS, 8);
> close (EMAILS);
>
> This is a whole new ball game and "struggling" to say the least. I would
> appreciate it if anyone can help me incorporate some code to the existing
> above.
> I have this tangled mess...
>
> open(EMAILS,"address.txt");
> @address=<EMAILS>;
> close(EMAILS);
>
> $add = grep{ /$email{'address'}/i } @email;
>
> if (@add) {
> $errormessage = "The address you entered, <B>$email{'address'}</B> is
> already in our mailing list";
> }
> exit;
>
> But then- Im only learning!
> Be kind :-)
> Thanks.
#------------------------------------------------------------
my $emails = 'address.txt';
open (EMAILS, ">>$emails") or die ("Can't open $emails: $!");
flock (EMAILS, 2);
seek (EMAILS, 0, 0); # rewind
my $found = 0;
while (<EMAILS>) {
chomp;
if (/^$email{'address'}$/i) {
$found++;
last;
}
}
if ($found) {
my $errormessage = "The address you entered, <B>$email{'address'}</B>
is already in our mailing list";
} else {
seek (EMAILS, 0, 2); # fast forward to eof
print EMAILS "$email\n";
}
close (EMAILS); # flock (EMAILS, 8) not needed or advised!
#------------------------------------------------------------
hth-
--
Michael Budash ~~~~~~~~~~ mbudash@sonic.net
------------------------------
Date: Sun, 24 Jun 2001 23:58:57 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: does DB_File work under win32 platforms?
Message-Id: <3B367E87.475D0363@rochester.rr.com>
Aman Patel wrote:
>
> well does it work under windoze perl like ActiveState's ActivePerl
Yes, it works fine. In fact it is the default for dbmopen in
ActiveState Perl.
--
Bob Walton
------------------------------
Date: 24 Jun 2001 22:40:08 GMT
From: Jim Monty <monty@primenet.com>
Subject: Re: fastest way to count lines in a bunch of files.
Message-Id: <9h5q88$nkq$1@nnrp1.phx.gblx.net>
Aman Patel <patelnavin@icenet.net> wrote:
> I need to be able to count lines in a bunch of files ...
From perlfaq5:
How do I count the number of lines in a file?
One fairly efficient way is to count newlines in the file. The
following program uses a feature of tr///, as documented in the
perlop manpage. If your text file doesn't end with a newline,
then it's not really a proper text file, so this may report one
fewer line than you expect.
$lines = 0;
open(FILE, $filename) or die "Can't open `$filename': $!";
while (sysread FILE, $buffer, 4096) {
$lines += ($buffer =~ tr/\n//);
}
close FILE;
This assumes no funny games with newline translations.
--
Jim Monty
monty@primenet.com
Tempe, Arizona USA
------------------------------
Date: Sun, 24 Jun 2001 23:56:11 -0400
From: "James Richardson" <time4tea@monmouth.com>
Subject: Re: fastest way to count lines in a bunch of files.
Message-Id: <9h6ctt$fri$1@slb3.atl.mindspring.net>
"Godzilla!" <godzilla@stomp.stomp.tokyo> wrote in message
news:3B364709.35BFB973@stomp.stomp.tokyo...
> > can anyone write small snippet, OR explain what to do instead.
>
> You are capable of writing your own test code and you are
> capable of reading about and researching this topic, certainly
> with this being a Frequently Asked Question.
>
> "...somewhat like...."? Programming is an exacting art affording
> no leeway for somewhat like nor something like. You either write
> your code correctly or incorrectly.
>
> Write your own variations on line counting and use
> the benchmark module to compare efficiency results.
> Why do you expect others to do your homework for you
> with this topic so well covered by Perl FAQ documentation?
>
Bloody hell..... why even bother replying. You may as well just tell the
bloke to 'fuck off'. If it really makes you feel so big to
be such a smart arse, why not go and teach five-year-olds, you will
definately have the programming edge on them!
Casey West said "We are responsible for the people we represent, like it or
not. So let's all grow up and represent them well."
Grow up kiddie.
I expect some flame for this.... I've been reading any contributing to
c.l.p.m for about 4 years on and off. Replies like this ( and yours is not
the first ), just make me sick. If somebody in my team were to ask a (
admittedly naive, but not stupid ) question like this, and you were to reply
as you have done above, I would find ways to remove you. What you say adds
nothing to the human experience.
James
------------------------------
Date: Mon, 25 Jun 2001 06:42:05 GMT
From: "Prarie Dawn" <prariedawn @hotmail.com>
Subject: Re: fastest way to count lines in a bunch of files.
Message-Id: <993451325.48915@atlas.corp.au.home.com>
Could you use grep?...
$num_lines = `grep -c ^ file.txt`;
------------------------------
Date: Mon, 25 Jun 2001 04:48:33 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Filehandles and close.
Message-Id: <3b36c27f.5c32$19e@news.op.net>
In article <3b2d8965$1@nexus.comcen.com.au>,
Kiel R Stirling <taboo@comcen.com.au> wrote:
>open F, '/etc/hosts.allow' or die $!;
>while( <F> ) {
> # do something..
>}
>
>
>At this point is there a need to call close on the filehandle?
>
>Doesn't while( <F> ) imply while the filehandle is open?
No. It implies 'while there is data left to be read'.
>So a call to close is really pointless, wasteful!
Not so. Consider:
open F, '/etc/hosts.allow' or die $!;
while( <F> ) {
# do something..
}
seek F, $position, 0; # LOOK AT THIS
while( <F> ) {
# do something else..
}
I hope this is instructive.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: 24 Jun 2001 20:29:31 -0700
From: nina_samimi@yahoo.com.au (Nina)
Subject: finding a file in a directory and reading it
Message-Id: <52fb0298.0106241929.740b4656@posting.google.com>
Hi,
I am trying to open a directory and get the latest file in that
directory and then open that file to read some information from it.
What I am using now is this part:
my @tempdir;
opendir(DIR, $mns_dir) || die("Cannot open directory");
while (my $tempfiles = readdir DIR) {
print $tempfiles if $tempfiles =~
/RPTPRINT.MNS206AR.24Jun01_13.37.48.Z/;
}
closedir DIR;
it gives me an error message "Use of uninitialized value at
qf_system_blast.pl line 179."
This file is compressed ".Z", can I open it compressed or no?
what am I doing wrong?
thanks
Nina
------------------------------
Date: Sun, 24 Jun 2001 23:50:26 -0400
From: "flash" <bop@mypad.com>
Subject: Re: finding a file in a directory and reading it
Message-Id: <JyyZ6.2064$yy2.805327@news20.bellglobal.com>
does $mns_dir have a value?
"Nina" <nina_samimi@yahoo.com.au> wrote in message
news:52fb0298.0106241929.740b4656@posting.google.com...
> Hi,
> I am trying to open a directory and get the latest file in that
> directory and then open that file to read some information from it.
>
> What I am using now is this part:
>
>
> my @tempdir;
> opendir(DIR, $mns_dir) || die("Cannot open directory");
> while (my $tempfiles = readdir DIR) {
> print $tempfiles if $tempfiles =~
> /RPTPRINT.MNS206AR.24Jun01_13.37.48.Z/;
> }
> closedir DIR;
>
>
> it gives me an error message "Use of uninitialized value at
> qf_system_blast.pl line 179."
>
> This file is compressed ".Z", can I open it compressed or no?
> what am I doing wrong?
>
> thanks
> Nina
------------------------------
Date: Sun, 24 Jun 2001 23:43:27 GMT
From: tony@svanstrom.com (Tony L. Svanstrom)
Subject: Re: how can i compile a perl program
Message-Id: <1evjbfw.npzogbj1am68N%tony@svanstrom.com>
Aman Patel <patelnavin@icenet.net> wrote:
> > You are expected to check the Perl FAQ *before* posting to
> > the Perl newsgroup.
>
> Yeah, RTM (boy i always wanted to say that).
Too bad you messed it up then, you forgot the F... :P
/Tony
--
########################################################################
I'm sorry, I'm sorry; actually, what I said was:
HOW WOULD YOU LIKE TO SUCK MY BALLS?
- South Park -
------------------------------
Date: Mon, 25 Jun 2001 05:30:06 -0000
From: www.fluxcenter.com <links@fluxcenter.com>
Subject: Re: how can i compile a perl program
Message-Id: <tjdj2uod54cbe7@corp.supernews.com>
#Simple
buy(perl sidekic) if(Nt);
buy(perl2exe) if(!NT);
Suraj Siddique wrote:
>
>
> how can i compile a perl program to make an excecutable
>
>
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Date: Sun, 24 Jun 2001 22:52:45 -0700
From: None <rig01@yahoo.com>
Subject: How can I get rid of lines with garbage in a large file . HELP!!!
Message-Id: <g8kdjt4s1u13ta85l1lu0lpcceqc13hhcc@4ax.com>
Hi :
I have a large file, with garbage inside (some lines have garbage),
How can I get rid of these lines with garbage.
Please help !!! how to do this in Perl?
Thanks in Adavace
Peter
------------------------------
Date: 24 Jun 2001 19:33:09 -0700
From: isterin@hotmail.com (isterin)
Subject: Re: How to automatically ANNOUNCE my module ?? With a script ?
Message-Id: <db67a7f3.0106241833.6ed47804@posting.google.com>
"Murat Uenalan" <murat.uenalan@gmx.de> wrote in message news:<9h4b1c$bkeko$1@ID-71895.news.dfncis.de>...
> Some of you module-authors do announce into perl newsgroups, some not ? Is
> there a script which does this job ?
A script?? I believe most announce themselves.
>Where can i get it ?
Never heard of one, I always announce manually to relavant newsgroups.
Ilya
>
> Thanks,
> Murat
------------------------------
Date: Sun, 24 Jun 2001 23:00:50 -0700
From: None <rig01@yahoo.com>
Subject: I have a large file, with garbage inside ; How can I get rid of these lines
Message-Id: <qqkdjtshg28majutgr6ff64eiaggo3p47j@4ax.com>
Hi :
I have a large file, with garbage inside (some lines have garbage),
How can I get rid of these lines with garbage.
Please help !!! how to do this in Perl?
Thanks in Adavace
Peter
------------------------------
Date: Mon, 25 Jun 2001 00:00:45 -0700
From: None <rig01@yahoo.com>
Subject: I have a large file, with garbage inside ; How can I get rid of these lines
Message-Id: <qcodjtk9v0na9k503e1fs5a7kn8b5msvr9@4ax.com>
Hi :
I have a large file, with garbage inside (some lines have garbage),
How can I get rid of these lines with garbage.
Please help !!! how to do this in Perl?
Thanks in Adavace
Peter
------------------------------
Date: 25 Jun 2001 04:51:33 GMT
From: Jim Monty <monty@primenet.com>
Subject: Re: I have a large file, with garbage inside ; How can I get rid of these lines
Message-Id: <9h6g0l$oih$1@nnrp1.phx.gblx.net>
None <rig01@yahoo.com> wrote:
> I have a large file, with garbage inside (some lines have garbage),
> How can I get rid of these lines with garbage.
This'll take the garbage out:
perl -ine 'print unless /garbage/' large_file
--
Jim Monty
monty@primenet.com
Tempe, Arizona USA
------------------------------
Date: Mon, 25 Jun 2001 02:16:28 +0400
From: "Oleg Bakiev1425878565" <boa@aaanet.ru>
Subject: Re: loading enviroment variables
Message-Id: <9h5osg$1154$1@pa.aaanet.ru>
"Oliver Gardi" <olga@student.unibe.ch>
news:3B3662C3.FE368776@student.unibe.ch...
> hi all
>
> i'am a perl newby, writing my first scripts. Now I have the problem,
> that I wan't to use variables I declared in a special sh-script,
> something like a config-file. I don't have any problems to access this
> variables from other shell scripts by using the command '.
> /etc/conffile'. So, the variables are loaded into the current shell
> enviroment.
> As I tried the same thing in my Perl-Script (system(".
> /etc/conffile");), it wasn't really successfull.
The shell's 'dot' command let you to run /etc/conffile in the context of the
current shell, that's why you can use environmemt variables defined in this
file. The perl's equialent of this is "do '/etc/conffile.pl'" .
/etc/conffile.pl should contain initialization of some global variables.
There is another way also. You can run '. /etc/conffile' before your perl
program and use special perl hash %ENV to access environment variables.
Oleg
------------------------------
Date: Mon, 25 Jun 2001 01:57:40 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: passing variables the 'right' way
Message-Id: <3b369a77.5846$2ca@news.op.net>
In article <x7sngpag8x.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
>>>>>> "MJD" == Mark Jason Dominus <mjd@plover.com> writes:
>
> MJD> Perl internally passes a pointer to the value of $x.
> MJD> There is no benefit to passing foo(\$x) instead.
>
>i beg to differ. . .if you want to use the ref in multiple or distant
>places in the sub, having a named ref would be better.
Not that that has anything at all to do with the question we were
discussing.
Context does matter.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: Mon, 25 Jun 2001 02:26:32 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: passing variables the 'right' way
Message-Id: <x7lmmh9twm.fsf@home.sysarch.com>
>>>>> "MJD" == Mark Jason Dominus <mjd@plover.com> writes:
MJD> In article <x7sngpag8x.fsf@home.sysarch.com>,
MJD> Uri Guttman <uri@sysarch.com> wrote:
>>>>>>> "MJD" == Mark Jason Dominus <mjd@plover.com> writes:
>>
MJD> Perl internally passes a pointer to the value of $x.
MJD> There is no benefit to passing foo(\$x) instead.
>>
>> i beg to differ. . .if you want to use the ref in multiple or distant
>> places in the sub, having a named ref would be better.
MJD> Not that that has anything at all to do with the question we were
MJD> discussing.
i think it does bear on this. assuming you want pass by ref in perl
there are two ways to use it. i use either style where i think it is
most appropriate. so just saying perl passes scalar values by ref is not
enough to answer the original post IMO.
MJD> Context does matter.
<OP>
my $var = slurp_a_file; #loads a big file,
pass_subroutine( \$var );
if i am right about the above code, how do we accept references in the
subroutine i.e.
sub pass_subroutine {
my $var = shift; #will this work if someone does
ass_subroutine( \$your_var ) ???
}
well will it work? or some special syntax is needed?
</OP>
he was asking about any special syntax which is what i would call
directly using $_[0] as it is not commonly done. so covering passing in
the scalar ref explicitly so you can used a named lexical is part of
that larger context.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
------------------------------
Date: Sun, 24 Jun 2001 21:56:39 -0400
From: David Coppit <newspost@coppit.org>
Subject: Re: Perl *is* strongly typed (was Re: Perl description)
Message-Id: <Pine.SUN.4.33.0106242149300.7403-100000@mamba.cs.Virginia.EDU>
On 22 Jun 2001, Randal L. Schwartz wrote:
> >>>>> "Cristian" == Cristian Cespedes V <ccespede@anakena.dcc.uchile.cl> writes:
>
> Cristian> yes, i undestand the questions. I can suposse that Perl is
> Cristian> weak typing (not strong typing)
>
> No, Perl has strong compile-time typing for primitive data types
> (scalars, arrays, hashes, filehandles), and strong run-time typing for
> user-defined data types (but weak compile-time typing).
True enough, but that's not enough to say that Perl has strong typing.
What about string versus numeric types?
$a = 1/3;
$b = 1/3 . '';
print $a*3,"\n";
print $b*3,"\n";
Perl auto-coerces strings into numbers and vice-versa, which makes it
really hard to say that it's strongly typed in the generally accepted
definition of the term. In this respect Perl is more like PL/I than
Ada. :)
Having said that (and perhaps offending many by comparing Perl to
PL/I), I don't think that this is a bad thing. I'd rather Perl help me
get work done than force me to be pedantic about variable types. I
haven't programmed in Ada, but I'm sure I'd find it a tedious as C++.
:)
BTW, is "bless" the Perl equivalent of a "void *" cast when it comes
to strong typing?
David
------------------------------
Date: 25 Jun 2001 05:15:52 GMT
From: dha@panix.com (David H. Adler)
Subject: Re: Perl Project
Message-Id: <slrn9jdi87.4ve.dha@panix2.panix.com>
In article <8f6b80cf.0106241047.b13abce@posting.google.com>, Dave
Goldstein wrote:
> If you are looking for an interesting new Perl project, this might be
> the thing for you.
You have posted a job posting or a resume in a technical group.
Longstanding Usenet tradition dictates that such postings go into
groups with names that contain "jobs", like "misc.jobs.offered", not
technical discussion groups like the ones to which you posted.
Had you read and understood the Usenet user manual posted frequently to
"news.announce.newusers", you might have already known this. :) (If
n.a.n is quieter than it should be, the relevent FAQs are available at
http://www.faqs.org/faqs/by-newsgroup/news/news.announce.newusers.html)
Another good source of information on how Usenet functions is
news.newusers.questions (information from which is also available at
http://www.geocities.com/nnqweb/).
Please do not explain your posting by saying "but I saw other job
postings here". Just because one person jumps off a bridge, doesn't
mean everyone does. Those postings are also in error, and I've
probably already notified them as well.
If you have questions about this policy, take it up with the news
administrators in the newsgroup news.admin.misc.
http://jobs.perl.org may be of more use to you
Yours for a better usenet,
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
If God didn't want us to eat animals, he wouldn't have made them out
of Meat. - Phillip, Goats, 20sep99
------------------------------
Date: Sun, 24 Jun 2001 20:09:34 -0400
From: "Todd W" <trw@uakron.edu>
Subject: Re: Problem reading large files (dumb question?)
Message-Id: <9h5vbb$72o$1@kira.cc.uakron.edu>
John W. Krahn <krahnj@acm.org> wrote in message
news:3B351D91.42695172@acm.org...
> "Richard J. Rauenzahn" wrote:
> > open OUT, ">d.dat" || die;
> ^^^^^^
> This doesn't do what you seem to think it does. You need to use "open()"
> or "or". to get die to do anything. You should also include the $!
> variable for a meaningful message.
that means this, right?
open OUT, ($foo || $bar);
using $foo as a filename if it is true, ortherwise using $bar...correct?
------------------------------
Date: 25 Jun 2001 03:48:32 GMT
From: ebohlman@omsdev.com (Eric Bohlman)
Subject: Re: Requires or All One File
Message-Id: <9h6cag$8lt$1@bob.news.rcn.net>
Steven Michaels <smichae@ilstu.edu> wrote:
> I have a rather large script, and I was wondering if it
> would be more, less, or as efficient if I split the files
> up into 'requires,' called from the main script.
Define "efficient." If you're talking speed, using require will be
(slightly) slower *if* you always require the same sections of code
everytime you run (if some sections of code only need to be brought in
under certain circumstances, then it will be faster). However, the first
rule of optimizing programs for speed is that you don't even bother
looking at any code that's executed only once per execution, and that's
what require is. If your application is sensitive to the slight speed
difference here, Perl is probably the wrong language in which to write it
(this is known as "straining at gnats and swallowing camels").
If you're talking about memory usage, there shouldn't be any difference
unless, again, it's possible to bring in different pieces of code under
different circumstances, in which case there's a slight advantage to
splitting.
If you're talking about maintainability and efficiency of development,
which are the most important factors economically (you can always throw a
faster processor or more memory at a program that's speed or space
inefficient, but throwing more programmers at a project that's inefficient
to develop or maintain seldom works and often makes things worse), then
splitting will definitely help.
------------------------------
Date: Sun, 24 Jun 2001 13:45:53 -0400
From: Mark-Jason Dominus <mjd@plover.com>
Subject: Re: simple reference question
Message-Id: <20010624174553.10025.qmail@plover.com>
inwap@best.com (Joe Smith):
> Shouldn't that be...
Yes, thanks for the correction.
------------------------------
Date: Mon, 25 Jun 2001 04:36:34 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Six degrees of separation
Message-Id: <3b36bfd1.5bed$1f4@news.op.net>
In article <tjcjr41p6ska74@corp.supernews.com>,
Greg Bacon <gbacon@hiwaay.net> wrote:
>: If God didn't want us to eat animals, he wouldn't have made them out
>: of Meat. - Phillip, Goats, 20sep99
>
>Didn't Alfred E. Neumann say that?
>
>Greg, who once thought Ted Nugent was first to say it
Could be, but it's hard for me to believe that is true, because the
idea is so obvious. I'm pretty sure I said this long ago, and at the
time I didn't think it was a bright inspiration. It's not like people
only started eating meat in the 1970's, you know. Probably some Roman
said it.
In any case, it's clearly anticipated by:
If the Jou-Jou had meant us not to eat people,
He wouldn't have made us of meat.
(Michael Flanders, 1956.)
Note Followup-To: line.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: Mon, 25 Jun 2001 05:57:07 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Why automatic translation to C will not make Perl programs faster
Message-Id: <3b36d2b2.5e1f$148@news.op.net>
* Why translating to C is unlikely to make your Perl program faster
(Mark Dominus, 20010624)
People often have the idea that automatically translating Perl to C
and then compiling the C will make their Perl programs run faster,
because "C is much faster than Perl." This article explains why this
strategy is unlikely to work.
* Short Summary
Your Perl program is being run by the perl interpreter. You want a C
program that does the same thing that your Perl program does. A C
program to do what your Perl program does would have to do most of the
same things that the perl interpreter does when it runs your Perl
program. There is no reason to think that the C program could do
those things faster than the perl interpreter does them, because the
perl interpreter itself is written in very fast C.
Some detailed case studies follow.
* Builtin Functions
Suppose your program needs to split a line into fields, and uses the
Perl 'split' function. You want to compile this to C so it will be
faster.
This is obviously not going to work, because the 'split' function is
already implemented in C. If you have the Perl source code, you can
see the implementation of 'split' in the file 'pp.c'; it is in the
function named 'pp_split'. When your Perl program uses 'split', Perl
calls this 'pp_split' function to do the splitting. 'pp_split' is
written in C, and it has already been compiled to native machine code.
Now, suppose you want to translate your Perl program to C. How will
you translate your 'split' call? The only thing you can do is
translate it to a call to the C 'pp_split' function, or some other
equivalent function that splits. There is no reason to believe that
any C implementation of 'split' will be faster than the 'pp_split'
that Perl already has. Years of work have gone into making 'pp_split'
as fast as possible.
You can make the same argument for all of Perl's other built-in
functions, such as join, printf, rand, readdir, and so on.
So much for builtin functions.
* Data structures
Why is Perl slow to begin with? One major reason is that its data
structures are extremely flexible, and this flexibility imposes a
speed penalty.
Let's look in detail at an important example: Strings. Consider
this Perl code:
$x = 'foo';
$y = 'bar';
$x .= $y;
That is, we want to append $y to the end of $x. In C, this is
extremely tricky. In C, you would start by doing something like this:
char *x = "foo";
char *y = "bar";
Now you have a problem. You would like to insert "bar" at the end of
the buffer pointed to by x. But you can't, because there is not
enough room; x only points to enough space for four characters, and
you need space for seven. (C strings always have an extra 'nul'
character on the end.) To append y to x, you must allocate a new
buffer, and then arrange for x to point to the new buffer:
char *tmp = malloc(strlen(x) + strlen(y) + 1);
strcpy(tmp, x);
strcat(tmp, y);
x = tmp;
This works fine if x is the only pointer to that particular buffer.
But if some other part of the program also had a pointer to the
buffer, this code does not work. Why not? Here's the picture of what
we did:
BEFORE:
Old buffer
x ----------->+---+---+---+---+
| f | o | o |nul|
z ----------->+---+---+---+---+
Here x and z are two variables that both contain pointers to the same
buffer. We want to append 'bar' to the end of the string. But the C
code we used above doesn't quite work, because we allocated a new
region of memory to hold the result, and then pointed x to it:
AFTER x = tmp:
Old buffer
+---+---+---+---+
z -----> | f | o | o |nul|
+---+---+---+---+
New buffer
+---+---+---+---+---+---+---+
x -----> | f | o | o | b | a | r |nul|
+---+---+---+---+---+---+---+
It's tempting to say that we should just point z to the new buffer
also, but in practice this is impossible. The function that is doing
the appending cannot know whether there is such a z, or where it might
be. There might be a hundred variables like z all pointing to the old
buffer, and there is no good way to keep track of them so that they
can all be changed when the array moves.
Perl does support a transparent string append operation. Let's see
how this works. In perl, a variable like $x does not point directly
at the buffer. Instead, it points at a structure called an SV.
('Scalar Value') The SV has the pointer to the buffer, and also some
other things that I do not show:
BEFORE $x .= $y
SV
+-------+ Old buffer
$x ---------->| | +---+---+---+---+
| * -------------->| f | o | o |nul|
$z ---------->| | +---+---+---+---+
+-------+
When you ask Perl to append 'bar' to $x, it follows the pointers and
finds that there is not enough space in the buffer. So, just as in C,
it allocates a new buffer and stores the result in the new buffer.
Then it fixes the pointer in the SV to point to the new buffer, and it
throws away the old buffer:
SV
+-------+ New buffer
$x ---------->| | +---+---+---+---+---+---+---+
| * -------------->| f | o | o | b | a | r |nul|
$z ---------->| | +---+---+---+---+---+---+---+
+-------+
Now $x and $z have both changed. If there were any other variables
sharing the SV, their values change as well. This technique is called
'double indirection', and it is why Perl can support operations like
'.='. A similar principle applies for arrays; this is why Perl can
support the 'push' function.
The flexibility comes at a price: Whenever you want to use the value
of $x, Perl must follow two pointers to get the value: The first to
find the SV structure, and the second to get to the buffer with the
character data. This means that using a string in Perl takes at least
twice as long as in C. In C, you just follow one pointer.
If you want to compile Perl to C, you have a big problem. You would
like to support operations like '.='. C does not support these very
well. There are only three solutions:
1. Don't support .=
This is a bad solution because after you disallow all the Perl
operations like '.=' and 'push' what you have left is not very
much like Perl; it is much more like C, and then you might as
well just write the program in C in the first place.
2. Do something extremely clever
Cleverness is in short supply this month. :)
3. Use a double-indirection technique in the compiled C code
This works, but the resulting C code will be slow, because you
will have to traverse twice as many pointers every time you
want to look up the value of a variable. But that is why
*Perl* is slow! In fact, Perl is *already* doing the
double-indirection lookup in C, and the code to do this has
already been compiled to native machine code.
So again, it's not clear that you are going to get any benefit from
translating Perl to C. The slowness of Perl comes from the
flexibility of the data structures. The code to manipulate these
structures is already written in C. If you translate a Perl program
to C, you have the choice of throwing away the flexibility of the data
structure, in which case you are now writing C programs with C
structures, or keeping the flexibility with exactly the same speed
penalty. You probably cannot speed up the data structures, because if
anyone knew how to make the structures faster and still keep them
flexible, they would already have made those changes in the C code for
Perl itself.
* Possible future work
It should now be clear that although it might not be hard to translate
Perl to C, programs will probably not get any faster as a result.
However, it's possible that a sufficiently clever person could make a
Perl-to-C translator that produced faster C code. The programmer
would need to give hints to the translator to say how the variables
were being used. For example, suppose you have an array @a. With
such an array, Perl is ready for anything. You might do $a[1000000] =
'hello', or you might do $a[500] .= 'foo'; or $a[500] /= 17; This
flexibility is expensive. But suppose you know that this array will
only hold integers and there will never be more than 1000 integers.
You might tell the translator that, and then, instead of producing C
code to manage a slow Perl array, the translator can produce
int a[1000];
and use a fast C array of machine integers.
To do this, you have to be very clever, and you have to think of a way
of explaining to the translator that @a will never be bigger than 1000
elements and will only contain integers.
People are planning these features for Perl 6 right now. For example,
Larry Wall, the author of Perl, plans that you will be able to declare
an array as
my int @a is dim(1000);
and then a Perl-to-C translator (or Perl itself) might be able to use
a fast C array of machine integers rather than a slow Perl array of
SV's. If you are interested, you may want to join the perl6-internals
mailing list.
For more information:
Larry Wall Apocalypse 2:
http://www.perl.com/pub/2001/05/03/wall.html
Damian Conway Exegesis 2:
http://www.perl.com/pub/2001/05/08/exegesis2.html
perl6-internals mailing list archive:
http://archive.develooper.com/perl6-internals%40perl.org/
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
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 1185
***************************************
