[13074] in Perl-Users-Digest
Perl-Users Digest, Issue: 485 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 12 14:17:17 1999
Date: Thu, 12 Aug 1999 11:15:23 -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 Thu, 12 Aug 1999 Volume: 9 Number: 485
Today's topics:
Re: Why use Perl when we've got Python?! (I R A Darth Aggie)
Re: Why use Perl when we've got Python?! (Ben Coleman)
Re: Why use Perl when we've got Python?! (Ben Coleman)
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! <tchrist@mox.perl.com>
Re: Why use Perl when we've got Python?! (Sean McAfee)
Re: Why use Perl when we've got Python?! (Greg Snow)
Re: Win32 Perl (newbie) <laurensmith@sprynet.com>
Re: Work around for signal handler crashes <tchrist@mox.perl.com>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 12 Aug 1999 16:10:35 GMT
From: fl_aggie@thepentagon.com (I R A Darth Aggie)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <slrn7r5sju.h4k.fl_aggie@thepentagon.com>
On 12 Aug 1999 09:09:20 -0700, Tom Christiansen <tchrist@mox.perl.com>, in
<37b2e3a0@cs.colorado.edu> wrote:
+ The reason, of course, is because the leading white space changed the
+ syntax! I cannot believe that the distaste you hold for using in Perl
+ dollars to specify variables or differently using [] to access an array
+ but {} to access a hash can possibly compare with the abhorrence that
+ fills a Perl programmer when he realizes that the number of spaces
+ at the front of the line is *syntactically significant*.
IIIIIIIIIIEEEEEEEEE! Is python related in some sick, twisted and demented
way to either f77 or punch cards? my head now hertz. I guess I knew that,
but seeing it in black & white...
+ Happy languages like FORTRAN come to mind.
Heh. I thought f90 got rid of the column-dependencies, but I'm not so
sure.
James
--
Consulting Minister for Consultants, DNRC
The Bill of Rights is paid in Responsibilities - Jean McGuire
To cure your perl CGI problems, please look at:
<url:http://www.perl.com/CPAN/doc/FAQs/cgi/idiots-guide.html>
------------------------------
Date: Thu, 12 Aug 1999 17:04:33 GMT
From: tnguru@termnetinc.com (Ben Coleman)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b2f8b3.2971392@news.mindspring.com>
On Thu, 12 Aug 1999 09:31:05 +0100, Ian Clarke <I.Clarke@strs.co.uk> wrote:
>Perl seems to be more of a rebellion against good language design, and
>while people claim that this makes it "more efficient" to code in, I
>have yet to see the proof - particularly if you include the time it
>takes to debug the code.
I haven't found Perl to take extensive debugging time -- and my background
is that of a 'top-down structured programming' developer whose other
preferred language is Modula-2(in part because I found that my Modula-2
programs took considerably less debugging than C programs of the same
size). I'm also finding that I'm turning to Perl for the small utilities I
once would have done in M2, because in Perl it gets done quicker.
Ben
--
Ben Coleman
Senior Systems Analyst
TermNet Merchant Services, Inc.
Atlanta, GA
------------------------------
Date: Thu, 12 Aug 1999 17:11:22 GMT
From: tnguru@termnetinc.com (Ben Coleman)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b2feb2.4506239@news.mindspring.com>
On Thu, 12 Aug 1999 16:52:11 +0100, Ian Clarke <I.Clarke@NOSPAM.strs.co.uk>
wrote:
>You have replied to my post
>as if it were an attack on Perl, which was not my intention. My
>intention is to find out what features Perl has that Python doesn't, and
>why I might want to use Perl when we have Python?
Part of the blame for that may go to your choice of Subject header. It
practically screams 'ADVOCACY TROLL', and primes the reader to expect an
attack on Perl. Something like 'Help me evaluate Perl from a Python
perspective' might have been better.
Ben
--
Ben Coleman
Senior Systems Analyst
TermNet Merchant Services, Inc.
Atlanta, GA
------------------------------
Date: 12 Aug 1999 11:20:19 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b30253@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc, Ian Clarke <I.Clarke@strs.co.uk> writes:
:That is not entirely true - I do have an open mind. The point is that
:as part of work, I may *need* to write Perl code, and I was really
:looking for some reasons why this might not be a bad thing... can anyone
:give me any?
Because learning is good. And because there are 10-100x more Perl
programmers and Perl programs in the world than there are the same for
Python, despite increasingly comparable longevity. Think about why
that might be.
Perl is hardly original in most of its approaches. Consider the famous
epithet, "Perl is the Cliff Notes of Unix". If you are a Unix programmer,
then this distilled essence of things already well known is familiar even
to the freshman Perl programmer. The corollary is of course that those
without a Unix background in C, shell, sed, awk, and a few dozen other
culture references find themselves even more lost. That's a good part of
why you see the some folks saying that Perl made complete sense to them
immediately, but others saying that this is quirky and unpredictable
and inconsistent and complicated. Consider the situation of Chinese
speaker trying to learn Italian. Everything is completely foreign and
unrelated to his accumulated experiences. Now consider the Spanish
speaker in the same class, also setting out to learn Italian. The Spanish
speaker finds intuitive and familiar everything that the Chinese speaker
finds confusing and strange.
Are you, perchance, a non-Unix person? That might explain your
antipathy over the same aspects of coding in which so many others
find comfort.
Now perhaps it is the case you really are an honest querent seeking
knowledge for its own sake, but your questions are so laden with negative
flash words and implied snipes that it is unlikely in the extreme that
you will accomplish more than inflame those whom you have knowingly or
unknowingly insulted or annoyed.
Nevertheless, I shall attempt to try. Keep in mind that you'll often
discover that the feature that one side holds as a strong point the other
side deems a weak one, and vice versa. I do not expect the following
exposition to differ significantly in that regard.
The core point of Perl is usefulness. It's not there to win awards on
complexity or cleverness or simplicity or minimalism or beauty or any
other goal that might detract from its real job: helping you get your
job done by making easy things easy and hard things possible. Try to
keep that in mind.
This concept is often expressed as the "Do What I Mean" principle, or in
short, "DWIM". When the language tries to do what you want it to do,
rather than requiring you produce that one exact incantation that will
accomplish your task, this is DWIM. DWIM makes the language react to
the user's expectations, which is nearly the opposite of these stoic and
spartan dialects, who, in a sad case of the tail wagging the dog, try to
make the programmer conform to their ideas, not the other way around.
Making life hard for the programmer and easy for the computer might
have made sense back when for the price of one computer, you could get
yourself a score or two of programmers; but today with those ratios
reversed, it makes little sense.
The DWIM principle can be found most high-level languages, be these Perl,
Python, Awk, or BASIC. In fact, you might even argue that the notions
of DWIM and high-levelness aren't all that far apart from each other.
Perl, however, is DWIMmer than Python in several areas that I'm about
to demonstrate. Some of Perl's DWIM is really "Do What a Unix Programmer
Means", but much of it applies to general programming issues irrespective
of your cultural background. The amount of dweomercraft required to
effect this magic is sometimes non-trivial, but the burden rests squarely
upon the maintainers of the Perl language itself, not upon the writers
and maintainers of Joe Random Perl code--which is as it should be.
One place that Perl's dweomer glows is in its automatic conversion between
character strings and numeric values. This is something Python doesn't
do. Consider what Python does if I feed it 42 on its standard input here:
% python
>>> import sys
>>> n = sys.stdin.readline()
42
>>> print n + 19
Traceback (innermost last):
File "<stdin>", line 1, in ?
TypeError: illegal argument type for built-in operation
Perl has no such difficulty, and this we consider a strength.
If I feed 42 into Perl's standard input for the following code:
$n = readline(*STDIN);
print $n + 19;
Then I simply get "61" out my standard output. It's quite obvious what
I meant to do, so Perl applies its dweomer to DWIM.
Another place where Python fails to apply DWIM in numeric values
is the integer/float boundary. Python forces the programmer
to specify whether something is an int or a float. Perl does not.
This is good, because usually a programmer just wants a number.
Consider
% echo 'print 3/4' | python
0
% echo 'print 3/4' | perl
0.75
Any nine-year old will tell you that three divided by four is
three quarters, or 0.75. Oddly, Python isn't up to the task.
You'll see the same problem here:
>>> n = 400
>>> n = n * n; print n
160000
>>> n = n * n; print n
Traceback (innermost last):
File "<stdin>", line 1, in ?
OverflowError: integer multiplication
That's because Python seems to want you to type this:
% python
>>> n = 400.0
>>> n = n * n; print n
160000.0
>>> n = n * n; print n
25600000000.0
>>> n = n * n; print n
6.5536e+20
>>> n = n * n; print n
4.294967296e+41
Perl, however, has no such problem:
% perl -d -e 0
DB<1> $n = 400
DB<2> $n = $n * $n; print $n
160000
DB<3> $n = $n * $n; print $n
25600000000
DB<4> $n = $n * $n; print $n
6.5536e+20
DB<5> $n = $n * $n; print $n
4.294967296e+41
Or course, a Perl programmer wouldn't write
$n = $n * $n
He'd either write
$n *= $n
or perhaps even
$n **= 2
This is especially nice for long expressions, such as
$n{"alpha"}{"beta"}{"gamma"}{"delta"} **= 2
The equivalent in Python is the obsequious
n["alpha"]["beta"]["gamma"]["delta"] = (
n["alpha"]["beta"]["gamma"]["delta"]
*
n["alpha"]["beta"]["gamma"]["delta"]
)
That's quite error prone, because you just had to type the same long thing
three times. Perl is safer in this way. I'll revisit this example later.
Meanwhile, have fun with your mouse.
You also see DWIM behaviour when converting between arrays (what
you would call lists) and hashes (what you would call dictionaries).
You can hold a list (what you would call a tuple), and these can be
automatically converted. This:
@array = ("fred", "wilma", "barney", "betty");
%hash = @array;
Is the same as:
%hash = ("fred", "wilma", "barney", "betty");
Because the list stored in the array will have its key-value pairs
re-interpreted when this is stored into the hash.
Another principle underlying much of Perl is that "things that
act different should look different". This allows you to write
programs in Perl that are *easier* to read, because different things
don't look like each other. Python tends to obscure this.
For example, that's one reason why when you want numeric ordering you
use "==", but when you want lexical ordering you use an operator that
looks completely different: "eq". Likewise, because an array and a hash
are, despite their interconvertibility, fundamentally different things,
they *look* different. Contrast Python's:
b = ["alpha", "beta", "gamma"]
c = { "fred" : "wilma", "barney" : "betty" }
print "b nought is", b[0]
print "c fred is", c["fred"]
with Perl's
@b = ("alpha", "beta", "gamma");
%c = ( "fred", "wilma", "barney", "betty");
print "b nought is", $b[0];
print "c fred is", $c{"fred"};
Or, if you prefer to work only with references (which are like pointers):
$b = ["alpha", "beta", "gamma"];
$c = { "fred", "wilma", "barney", "betty"};
print "b nought is", $b->[0];
print "c fred is", $c->{"fred"};
Accessing an array and accessing a hash are different operations.
They look very different. It's obvious to the reader what's going on.
They can look at %h and @a and know these are different.
They can look at $h{"fred"}" and $a[0] and know these are different.
Another place is quotes. Single quotes look different from double quotes.
And they do very different things: the former is an uninterpolated
literal, whereas the latter expands variables and C-style backslash
escapes.
Perl consistently produces better error messages than Python.
Here's one example:
% echo 'print f()' | python
Traceback (innermost last):
File "<stdin>", line 1, in ?
NameError: f
% echo 'print f()' | perl
Undefined subroutine &main::f called at - line 1.
After a while, you just want to take all your mysterious "name errors"
and "syntax errors" and send them one at a time to Guido.
Let's finish up go back to DWIM. Python is really not very good at
autoallocation, at least when compared to Perl. Consider for example:
@array = ("alpha", "beta", "gamma");
$array[3] = "delta";
That's just fine in Perl. It's not fine in Python, because Python
won't automatically grow an array.
>>> a = ["alpha", "beta", "gamma"]
>>> a[3] = "delta"
Traceback (innermost last):
File "<stdin>", line 1, in ?
IndexError: list assignment index out of range
Instead, you need to remember to use
a.append("delta")
if it doesn't exist yet. This complexity forces the programmer who wants
to assign "delta" to the third slot (there's a zeroth slot) of the list
(Python parlance) to do something totally different in one situation
than they have to do in another.
In Perl, this is much easier. In fact, it just does what you mean
right from the start.
Oddly enough, Python does let you grow dictionaries automatically.
In fact, you have to do so. Even though they are initialized
differently
a = ["alpha", "beta", "gamma"]
d = {"fred": "wilma", "barney": "betty"}
But they look the same on access:
print a[0]
print d["fred"]
You aren't able to add something to them the same way. For
adding a new slot to the dictionary where there wasn't one,
you can just use
d["more"] = "stuff"
but the list requires a completely different syntax. In fact,
it requires a function call! And you can't call
d.append("more" : "stuff")
Perl is much more consistent here than Python is.
Finally, consider this code in Perl. This is a complete
program.
$n{"alpha"}{"beta"}{"gamma"}{"delta"} = 400;
$n{"alpha"}{"beta"}{"gamma"}{"delta"} **= 2;
print $n{"alpha"}{"beta"}{"gamma"}{"delta"}, "\n";
Grab your mouse and do the old snarf-and-barf into Perl. You'll see
that it prints 160000 as we saw before.
To do the equivalent in Python is remarkably more tedious.
n = {}
n{"alpha"} = {}
n["alpha"]["beta"] = {}
n["alpha"]["beta"]["gamma"] = {}
n["alpha"]["beta"]["gamma"]["delta"] = 400
n["alpha"]["beta"]["gamma"]["delta"] = (
n["alpha"]["beta"]["gamma"]["delta"]
*
n["alpha"]["beta"]["gamma"]["delta"]
)
print n["alpha"]["beta"]["gamma"]["delta"]
Notice all those steps you have to go through? It's true that
you can get by with just
n = {'alpha': {'beta': {'gamma': {'delta': 400}}}}
But the point is that Python refused to autoallocate for you.
You have to do all the hard work on your own. Perl, on the other
hand, is much more helpful here, applying DWIM to do what you meant.
And if you think that the dictionary example is rough, consider
this Perl code:
$n[20][20][20][20] = 400;
$n[20][20][20][20] **= 2;
print $n[20][20][20][20], "\n";
Because a Python list can't grow by direct assignment the way
a Perl array, a Python dictionary, or a Perl hash can, you can't
just do repeated assignments in Python like
n = []
n[20] = []
n[20][20] = []
n[20][20][20] = []
n[20][20][20][20] = 400
That still won't work, of course.
I've typed for you all morning long. I hope that this gives you a feel
for some fundamental ways where Perl is more programmer-friendly than
Python is. There are others, such as scoping issues, but these should
suffice to provide you something of the flavor.
--tom
--
"It's ironic that you would use a language as large as English to express
so small a thought."
--Larry Wall
------------------------------
Date: 12 Aug 1999 11:28:15 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37b3042f@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
fl_aggie@thepentagon.com (I R A Darth Aggie) writes:
:+ Happy languages like FORTRAN come to mind.
:
:Heh. I thought f90 got rid of the column-dependencies, but I'm not so
:sure.
You think that's rich, you ought to see what happens to people
who set their tabstops to 3 or 4. :-)
--tom
--
The computing field is always in need of new cliches. -- Alan Perlis
------------------------------
Date: Thu, 12 Aug 1999 17:52:25 GMT
From: mcafee@waits.facilities.med.umich.edu (Sean McAfee)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <tRDs3.1443$J72.232020@news.itd.umich.edu>
In article <37AAFAD1.A032765B@NOSPAM.strs.co.uk>,
Ian Clarke <I.Clarke@NOSPAM.strs.co.uk> wrote:
>I know this sounds like flame-bait, but I am genuinely curious as to
>what Perl might have to offer that Python doesn't.
Here's one anecdotal data point:
To help me learn Python, I decided to rewrite some of my Perl scripts
in Python. The first script I chose for conversion was called "getfile";
it grabs a file via FTP and prints it on stdout. Here it is:
======================================================================
#!/usr/local/bin/perl
use Net::FTP;
@ARGV == 3 || die;
($host, $userID, $file) = @ARGV;
system("stty -echo");
chomp($passwd = <STDIN>);
system("stty echo");
$ftp = new Net::FTP $host;
login $ftp $userID, $passwd;
get $ftp $file, \*STDOUT;
quit $ftp;
======================================================================
I use it mainly when I want to insert a remote file into my editor (vim).
I type ":r!getfile host login dir/file", wait a second, type my password,
and the file appears on the screen. Very convenient.
I began the conversion by looking for an FTP module for Python. It turns
out that one comes with the standard distribution. I began reading the
documentation for the module, and before long I couldn't believe what I was
reading. You actually have to know the FTP protocol to use Python's FTP
module! You need to open your own destination file and send a command to the
remote FTP server by calling ftp.retrlines('RETR ' + filename, myfile.write).
Ridiculous! Modules are supposed to hide such implementation details from
the user, not force the user to deal with them. Meanwhile, Perl's FTP
module uses essentially the same interface as the "ftp" program I've always
used.
As for why I use Perl, one reason is that I often need to perform small
data-munging tasks that can often be done in one line or less of Perl.
For instance, I once had a C program that wrote to a log file lines of
the form "time:number", where "time" is the usual Unix epoch time (seconds
since 1/1/1970). Later when I wanted to scan the logs, transforming the
Unix time into English, I did it like so:
perl -pe 's/(\d+)/localtime $1/e' logfile | more
Another time, I needed a sorted list of all unique alphabetic prefixes
for all files in a certain directory.
perl -e '$, = "\n"; /^([A-Z]+)/ && $a{$1}++ for </dir/*>; print sort keys %a'
Even Python advocates concede that Python isn't well-suited to one-liners
like this. Well, guess what? I use one-liners more often than I write
larger, more permanent programs.
Oh, and there's also the fact that Perl is faster than Python at darn near
everything. That's the icing on the cake.
--
Sean McAfee mcafee@umich.edu
print eval eval eval eval eval eval eval eval eval eval eval eval eval eval
q!q@q#q$q%q^q&q*q-q=q+q|q~q:q? Just Another Perl Hacker ?:~|+=-*&^%$#@!
------------------------------
Date: 12 Aug 1999 17:33:28 GMT
From: snow@statsci.com (Greg Snow)
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <7ov0h8$7b5$1@junior.statsci.com>
In article <37B28649.9C7F0C1E@NOSPAM.strs.co.uk>,
Ian Clarke <I.Clarke@strs.co.uk> wrote:
>
[snip]
>I am glad you could care less, but if someone would only provide me with
>some solid reasons for why I might want to use Perl over Python (other
>than wishy washy "Perl is more efficient to code in" or "I tried Python
>and didn't like it" comments) then I might consider trying Perl.
I'll take a stab at telling you a couple of things I like about Perl,
maybe they will help you decide. I don't know Python, so I can't give you
a direct comparison (I looked at an intro to Python once and decided that
other things had higher priority on my time).
Remember that a computer language is as much (or more) about
communication between people as it is between a person and the computer.
The more expressive a language is, the more subtleties need to be learned.
I heard about a language (human, not computer) that was developed for mine
workers in southern Africa. The mines employed people from very different
language backgrounds (from Afrikaans to Xhosa) and so they invented their
own language that was a mix of these, but with the advantage that it was
very easy to learn, in fact it was simple enough that most people could
learn the entire language in 2-3 days. The drawback was that it was very
limited for things beyond specifically mine related communication, there
is no word for honeybee and the phrase used translates roughly to "little
man who makes jam with his hands". It is simmilar with computer
languages, a simple language may be quicker to learn, but you can't
express very much with it. Perl has a lot of syntax and a lot of
flexibility, this may mean that it takes longer to learn, but you can
express a lot more with it (even write poetry).
When you read someone elses program, there are 2 major influences on the
syntax used: 1. what the author of the program was thinking when they
wrote the program and 2. what the designer of the language was thinking
when they wrote the language. Since a programmer may be implementing
something that the language designer never thought of. In this case I
would hope that number 2 does not dominate number 1. Larry was thinking
"flexibility" when he wrote Perl, so reading Perl programs reflects mostly
the programmers thinking with very little intrusion by Larry's
restrictions.
A couple of examples:
a common Perl idiom is
open MY, $file or die "$!\n";
(that even parses to humans like english).
It could be written equivalently as:
if( !open(MY,$file) ) { die "$!\n" }
both forms cause the computer to do the same thing (try to open a file and
quit with an error message if it can't), but how do people parse them
(since I don't read minds I'll just talk about how I parse them).
Imagine a first read through of the program to get a general idea of what
it does:
In the case of the if statement, the first thing I see is the "if", think
this is a conditional what does the expression inside the ()'s return, ah
I need to negate that and so if the file can't be opened then it executes
die ... oh! this is just the error catching for a first time through I
only care about things going right, not the exceptions. Go back and find
the open statement to see what filehandle is associated with which file,
skip down to find next statement.
Let's compare with the "or" form. The first thing I see is the "open", I
think "a file is being opened and associated with the filehandle MY", then
when I see the "or" I think "the exception is dealt with", I then skip the
rest of the line (that's for the 3rd or 4th reading) and quickly find the
next expression.
The important thing here was the open command, the if statement distracted
from that, the "or" form emphasized it.
Another example:
say we have a loop that goes through a file a line at a time
while(<MY>){
...
}
among other things computed in the loop, we want a count of the number of
non-blank lines. Perl gives us the flexibility to do this 4 ways
(actually more than 4, but I'll just focus on these 4):
1. if( /\S/ ){ $count++ }
2. unless( /^\s*$/ ){ $count++ }
3. $count++ if /\S/;
4. $count++ unless /^\s*$/;
All 4 of those give the same result, but what do they say to someone
reading the program (maybe even the programmer rereading at a later date).
Options 1 & 2 put more emphasis on the condition (and in some cases that
may be what we want), options 3 & 4 put more emphasis on the counting
going on (probably what we want most of the time). The regular
expressions may also convey a different message, 1 & 3 say increment when
you find any character in the line that is not a whitespace character, 2
& 4 say increment unless you have a line that only contains optional
whitespace between the begining and the end of the line, equivalent to the
computer, but may suggest subtle differences to the reader. I also tend
to see the unless cases (2 & 4) as indicating exceptions (rare), we will
increment most of the time **unless** something indicates that we
shouldn't. The "if" versions imply that most lines will be blank and we
should only increment when something special tells us to. 4 different
statements that tell the computer (who only cares about what to do, not
about understanding the why) the same thing, but convey different meanings
of "why" to the human reader of the program.
I hope this helps you see why some of us think the extra syntax is worth
the effort it takes to learn.
--
-------------------------------------------------------------------------------
Gregory L. Snow | Inertia makes the world go round,
(Greg) | Love makes the trip worth taking.
snow@statsci.com |
------------------------------
Date: Thu, 12 Aug 1999 09:55:46 -0700
From: "Lauren Smith" <laurensmith@sprynet.com>
Subject: Re: Win32 Perl (newbie)
Message-Id: <7ouuah$b7g$1@brokaw.wa.com>
James Liu wrote in message ...
>I got Oreilly's Learning Perl (Llama book). I'm running Windows 98.
what
>should I know about how perl runs on windows? please help.
Go get Perl at www.activestate.com . That is the first step.
Lauren
------------------------------
Date: 12 Aug 1999 11:50:34 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Work around for signal handler crashes
Message-Id: <37b3096a@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc,
Philip_Dye@norstanconsult.com writes:
:After diving deep into the perl code I found the real problem in how the
:signal handler setup code. It seems the standard setup code used for other
:procedures is being used to setup installed signal handlers. Given that
:such code calls malloc() this really isn't kosher.
We know. We're thinking about it.
--tom
--
If a `religion' is defined to be a system of ideas that contains unprovable
statements, then Goedel taught us that mathematics is not only a religion,
it is the only religion that can prove itself to be one.
-- John Barrow
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq" from
almanac@ruby.oce.orst.edu. The real FAQ, as it appeared last in the
newsgroup, can be retrieved with the request "send perl-users FAQ" from
almanac@ruby.oce.orst.edu. Due to their sizes, neither the Meta-FAQ nor
the FAQ are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq" from
almanac@ruby.oce.orst.edu.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V9 Issue 485
*************************************
