[18263] in Perl-Users-Digest
Perl-Users Digest, Issue: 431 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 6 21:11:02 2001
Date: Tue, 6 Mar 2001 18:10:13 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <983931013-v10-i431@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 6 Mar 2001 Volume: 10 Number: 431
Today's topics:
Re: Perl fortune database - where? (was: Dynamic naming <iltzu@sci.invalid>
Re: Perl fortune database - where? (was: Dynamic naming (Abigail)
Re: PHP Help me please !!! <patrickolson@qwest.net>
Re: pi day <mischief@velma.motion.net>
Re: RFC: FAQ3 update -- Using less memory <mjcarman@home.com>
Re: RFC: FAQ3 update -- Using less memory <mjcarman@home.com>
Set Socket to TCP_NODELAY <Heiko.Brandhorst@gmx.de>
Re: Set Socket to TCP_NODELAY <uri@sysarch.com>
Re: statement for(list); <mischief@velma.motion.net>
Re: statement for(list); (Martien Verbruggen)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 6 Mar 2001 23:44:52 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Perl fortune database - where? (was: Dynamic naming of arrays or hashes)
Message-Id: <983921608.13251@itz.pp.sci.fi>
In article <u93dcqokti.fsf@wcl-l.bham.ac.uk>, nobull@mail.com wrote:
>
>OK, who's maintaining a Perl "fortune" database? That's gotta be
>worthy:
>
>[Elimitiating symrefs so you can "use strict"]... is a little like
>saying you have decided to stop setting your furniture on fire,
>because you want to be able to turn your smoke alarms back on.
> -- Mark Jason Dominus in c.l.p.misc
If someone wants to compile a proper database, allow me to contribute my
collection of comp.lang.perl.m* sigquotes:
"If you don't use use strict; you're on your own anyway."
-- Abigail in comp.lang.perl.misc
"The screwdriver *is* the portable method." -- Abigail in c.l.p.m
Please ignore Godzilla | "By promoting postconditions to
and its pseudonyms - | preconditions, algorithms become
do not feed the troll. | remarkably simple." -- Abigail
"Your example is a pathological extreme. But then :) I would expect nothing
less in this forum." -- T. Alex Beamish in comp.lang.perl.misc
"What gets me is 'extra virgin olive oil'. I always thought virginity was
a binary state." -- Craig Berry in comp.lang.perl.misc
"Monitoring a nuclear power plant? Well... maybe not. Not sure I'd trust
C for this either as a core dump could lead to, well, a core dump."
-- Michael Carman in comp.lang.perl.misc
"TIMTOWTDI, but did you have to pick the ugliest way you could find?"
-- after Michael Carman in comp.lang.perl.misc
"Usenet is a lousy way to get quick service. It's even worse if you want
quick and *correct* answers." -- David Cassell in comp.lang.perl.misc
"Congratulations, you have just reinvented the wheel. *And* made it square."
-- Simon Cozens in comp.lang.perl.misc
"TIMTOWTDI often means there is more than one really bad way to do it."
-- after Tim Cuffel in comp.lang.perl.misc
"When they say that Perl is a `glue language', what they really mean is
that it is good for cleaning up after the mistakes of other programs."
-- Mark-Jason Dominus in comp.lang.perl.misc
"My previous boss . . . was never afraid to make himself look silly if it
was a step to acquiring new knowledge, and we all respected him for that."
-- Alan J. Flavell in comp.lang.perl.misc
"Opinions may of course differ on this topic, but wouldn't it be better
to persuade the hon. Usenaut, as a first priority, to post accurate
information, before persuading them to abandon this remarkably accurate
indicator of usenet bogosity?" -- Alan J. Flavell in c.l.p.misc
"I don't know what your original problem is, but I suggest to use a hash."
-- Rafael Garcia-Suarez in comp.lang.perl.misc
"Do you replace the battery with a grapefruit when your car won't start,
just in case that's the problem?" -- Sam Holden in comp.lang.perl.misc
"'Manners' evolve to avoid conflict in crowded situations. Usenet (and this
newsgroup in particular) is crowded." -- Tad McClellan in clp.misc
"Get real! This is a discussion group, not a helpdesk. You post
something, we discuss its implications. If the discussion happens to
answer a question you've asked, that's incidental." -- nobull in clpm
"I leave that to Abigail. I won't say that she heales the sick, but they
sure never complain anymore..." -- Alex Rhomberg in comp.lang.perl.misc
"Unless you perform unnatural acts, indexes start at 0, not 1."
-- Larry Rosler in comp.lang.perl misc
"If circles were squares, this would be an accurate value of pi."
-- Joe Schaefer in comp.lang.perl.misc
"Yup. Luckily I'm using PSI::ESP_XS, so it's all quite fast"
-- Martien Verbruggen in comp.lang.perl.misc
"Did I mention that I can't tell you how to get rich? If I could, I'd be
rich, and not here." -- Martien Verbruggen in comp.lang.perl.misc
"However, SQL is better in this regard, tempting you from the start in MySQL
with the good old 'insert into users .....'" -- W K in comp.lang.perl.misc
"Yes I know you can see it in MSIE, but you could feed MSIE a banana and
it would think it was HTML" -- Jeff Zucker in comp.lang.perl.misc
And, to close this post, let me pick a rather universally appropriate
quote from a clpm regular in another newsgroup:
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
"/* If you don't understand, don't touch */" -- Abigail in the monastery
------------------------------
Date: 7 Mar 2001 01:20:48 GMT
From: abigail@foad.org (Abigail)
Subject: Re: Perl fortune database - where? (was: Dynamic naming of arrays or hashes)
Message-Id: <slrn9ab37g.7vp.abigail@tsathoggua.rlyeh.net>
Ilmari Karonen (iltzu@sci.invalid) wrote on MMDCCXLIV September MCMXCIII
in <URL:news:983921608.13251@itz.pp.sci.fi>:
`' In article <u93dcqokti.fsf@wcl-l.bham.ac.uk>, nobull@mail.com wrote:
`' >
`' >OK, who's maintaining a Perl "fortune" database? That's gotta be
`' >worthy:
`' >
`' >[Elimitiating symrefs so you can "use strict"]... is a little like
`' >saying you have decided to stop setting your furniture on fire,
`' >because you want to be able to turn your smoke alarms back on.
`' > -- Mark Jason Dominus in c.l.p.misc
`'
`' If someone wants to compile a proper database, allow me to contribute my
`' collection of comp.lang.perl.m* sigquotes:
Here are some more snippits from Perl related sources:
%%
You can program badly in any language (even Pascal if you try hard enough).
[Nick Kew in `nascent FMTEYWTK on OO Perl vs C++']
%%
I can do this because Perl lays down like a wanton woman and lets me
have my way with her.
[Geoff Gerrietts in `nascent FMTEYWTK on OO Perl vs C++']
%%
The idiotic interaction between the filesystem notation
and the C syntax of escaping characters is one that only
an idiot ignorant of history, programming, and computer
science could have devised. Who did this stupid thing?
"What has it gots in its slasheness? Curse the Gates!
We hates him forever!"
[Tom Christiansen in `binary writes...'
<news:4t7tbg$e8n@csnews.cs.colorado.edu>]
%%
Yes: Java's main advantage over Perl is that it's hard to use for casual
programmers, so keeps all but the most intrepid programmers away from it.
It has no decent support for string processing, allowing you to spend
hours at useless debugging. It has a very restrictive and static system
to make sure you don't try anything interesting. It makes sure that you
use objects, by golly, because James Gosling said so. It's easy for C++
programmers to use, and hard for shell or BASIC programmers to use. It
also only runs on a few systems, locking its customers into a a closed
system and restricting their options.
[Tom Christiansen in `Java Vs. Perl'
<news:53k0v7$a36$1@csnews.cs.colorado.edu>]
%%
Java is cute. Perl is practical.
[Nathan V Patwardhan in `Java Vs. Perl'
<news:53lq5i$svc@prometheus.acsu.buffalo.edu>]
%%
The Internet Revolution was founded on open systems: an open system is one
whose software you can look at, a box you can unwrap and play with. It's
not about secret binaries or crippleware or brother-can-you-spare-a-dime
shareware. If everyone always had hidden software, you wouldn't have
1/100th the useful software you have right now.
And you wouldn't have Perl.
[Tom Christiansen in `The new Camel and compiling perl'
<news:53mal3$4b5$1@csnews.cs.colorado.edu>]
%%
What could you say? The guy had no business asking the question and
no use for the answer. Maybe the right answer would have been to cut
off his finger or something. I dunno.
[Mark Atwood in `Getting your questions answered'
<news:v6ralvqupz.fsf_-_@alt.dev.ampersand.com>]
%%
Before you think UNIX is too family-oriented, note that all
children must die.
[Eric F. Johnson in `Cross-Platform Perl'
<ISBN: 1-55851-483-X>]
%%
Um, my OED has neither a CLI nor a GUI -- it's made of paper.
[Tom Christiansen in `Re: Camel 2: Errata, Corrigenda,
et Desiderata (chapters 0-3)'
<news:59418u$qki$1@csnews.cs.colorado.edu>]
%%
The Vikings aren't dead; they've only been domesticated.
[Terje Bless in `Re: Reading perl out loud'
<news:link-ya02408000R1812961503380001@news.uit.no>]
%%
EMACS belongs in <sys/errno.h>: Editor Too Big!
[Tom Christiansen in "regexp's in XEmacs vs. Perl"
<news:5e2bt3$3km$2@csnews.cs.colorado.edu>]
%%
You call THIS sugar? I'd say it's syntactic vinegar. One can at least read
lambda notation.
[Vladimir Alexiev in
`continuation-passing and tail-recursion'
<omohci1gz2.fsf@tees.cs.ualberta.ca>]
%%
I don't know - most books on Java at least present a lot of
good reasons to learn Perl.
[David Alan Black in `What's a bad Perl book?'
<news:5h99fc$m39@pirate.shu.edu>]
%%
In a business, marketroids, salespukes, and lawyers have
different goals from those who actually do work and produce something.
[Tom Christiansen in `Microsoft and POSIX compliance'
<news:5jdcls$b04$2@csnews.cs.colorado.edu>]
%%
Vi is still around because they got it right the first time and
nothing better has come along. (Emacs is just a bloated vi clone! :))
[Scott McMahan in `any editor for perl?'
<news:5n459g$1ie$1@mainsrv.main.nc.us>]
%%
Vi isn't a particularly good editor for those whose brains haven't been
previously damaged by its interface. Emacs suffers from the same problem and
comparing the two is mostly pointless. I don't particularly like vi, but 1) I
was forced to use it a long time ago when there weren't any alternatives
(well, none that my CS department was willing to investigate), 2) given a host
of crappy unix editors, I stick with the devil I know, 3) I could never get
the hang of emacs (Ctrl-Esc-Esc-Backspace-Toilet_Seat...), and 4) I trust vi
to simply mangle my text on a wrong keystroke, not wipe my filesystem,
refinance my house, make large political contributions on behalf of dead
relatives, drive while intoxicated or consort with demons, all of which (I
suspect) emacs could perform with an accidental Meta-Meta-Keystroke.
[Bob Apthorpe in `any editor for perl?'
<news:5nacai$lr1@news.jump.net>]
%%
The problem is that you need to use Perl for a year before your sense of
surprise matches Perl's
[ChipDude on IRC/#perl]
%%
C with decent text manipulation isn't C. C is for creating good
things, it itself is not a cool thing.
[ChipDude on IRC/#perl]
%%
Signals are for people who can't handle sequential execution.
[ChipDude on IRC/#perl]
%%
UNIX people really only need tar and gzip, to get by.
[William Middleton in `Perl Package Manager - expanded'
perl5 porters: <199708210451.VAA03238@ducks>]
%%
Well, Bill Gates *did* invent the Internet, right after he founded Sun
Microsystems. Of course, it was called uucp then, and it was secret,
because the DoD wanted a network which would continue working even if
the commies infected all the modems with viruses. I can't understand
what you've got against win95 - after all, it's really just NT with a
registry thingy changed, and we all know NT is the best platform for
mission-critical networked systems. Unix was invented in the 60's by
hippies and faggots, and Linus Torvalds' name backwards is something
satanic, and how can you trust an OS written by someone named after a
character from "Peanuts" anyway?
[Malcolm Ray in `Whoo hoo'
<news:slrn5vor3h.hsc.uhaa032@uhaa022.cc.rhbnc.ac.uk>]
%%
The following two statements are usually both true:
There's not enough documentation.
There's too much documentation.
[Larry Wall in `close(STDOUT) breaks unrelated FileHandle'
<199709020026.RAA08431@wall.org>]
%%
Of course, this being Perl, we could always take both approaches.
[Larry Wall in `sub attributes'
<199709021744.KAA12428@wall.org>, 2 Sep 1997]
%%
Chess is a game. Magic is a game. Maj Jongg and Shafskopf are games.
D&D is a game. Even pinball is a game. But video diversions are merely
a way to weed out those with latent epilepsy.
[Tom Christiansen on IRC/#perl. 4 Sep 1997]
%%
But the possibility of abuse may be a good reason for leaving
capabilities out of other computer languages, it's not a good reason
for leaving capabilities out of Perl.
[Larry Wall in `Macros'. {perl5-porters}
<199709251614.JAA15718@wall.org> 25 Sep 1997]
%%
Besides, I wasn't trying to help them understand. I was only trying
to help them think they understand.
[Larry Wall in `[PERL] the \X "cut" metacharacter'
{perl5-porters} <199710211647.JAA17957@wall.org>
%%
And don't tell me there isn't one bit of difference between null and
space, because that's exactly how much difference there is. :-)
[Larry Wall]
%%
I have a gut feeling that Perl could ultimately replace COBOL as the
data-mangling glue of choice for large DP shops.
[Charlie Stross in `Perl and Privacy' {perl5-porters}
<mid:19971203122241.57034@antipope.org> 3 Dec 1997]
%%
Seems to me it used to be considered rude to be a random newbie and ask
everyone else to solve a problem for you and be done with it.
[Abby Franquemont in `General Rudeness'
<news:6h5lfl$r6d$1@ucan.foad.org> 16 April 1998]
%%
Tom P. is a clever perl script, a la Eliza. Read thirty of his posts
and look at the heavy redundancy. Humans are not that patient.
Elijah
--
which is not to say there is not also a human Tom P, he teaches for Stonehenge
[Eli the Bearded in `What a Crappy World'
<news:eli$9806252326@qz.little-neck.ny.us> Jun 26, 1998]
%%
Maybe Pi looks like this:
=for C
i++; /* add 1 to i */
=end
=for C++
i.value() += 1; // add 1 to i, probably
=end
=for Java
system().foo().bar().i().value().please().increment(); // ???
=end
[Larry Wall in `Pi' {perl5-porters}
<199808050540.WAA24389@wall.org>, Aug 5, 1998]
%%
Because the programmer knows what he or she wants to optimize for, and
the language designer doesn't. Plus, it's more fun.
Dink Thifferent.
[Larry Wall in `Perl & Java - differences and uses'
<news:6u0lq0$ij1@kiev.wall.org> {comp.lang.perl.misc}
19 Sep 1998]
%%
[To George Reese]
Don't let the frustration of not being able to form a coherent argument
get to you, George. Instead, try to learn something from those who
frustrated you by outperforming you.
[Chris Russo in `Perl & Java - differences and uses'
<news:news-2409980834070001@buzz.hq.alink.net> 24 Sep 1998.
{comp.lang.perl.misc}]
%%
On the sociology axis, anyone who's read the whole of the thread
now understands Internet Flamewar Rule Number Twelve: if you
simply have no clue, don't pretend you do. Perhaps some young
impressionable kindling wannabe, learning from the example of
George Reese, will now go learn something before posting --
a positive result, wouldn't you agree?
[Felix S. Gallo in `Perl & Java - differences and uses'
<news:6ue03t$49a@enews4.newsguy.com> 24 Sep 1998.
{comp.lang.perl.misc}]
%%
Perl should only be studied as a second language. A good first
language would be English.
Don't teach Perl as a first language. Instead, find a nice small
language and teach the subset of Perl that corresponds to it.
The trouble with teaching Perl as a first computer language is that your
students won't appreciate it till they start learning their second.
The trouble with teaching Perl as a second language is that there's
no single suitable first language to go in front.
Don't teach them Perl as a first language, or they'll never make it to
their second language...
Don't let anyone tell you what your first computer language should be
before you've learned several.
Perl can certainly be used as a first computer language, but it was
really designed to be a *last* computer language.
Well of *course* Perl should not be taught to everyone. It should only
be taught to people who want to like their computers.
Honk if you love Perl! (or strawberries!)
[Larry Wall in `Are there any "perl.newbie" group or forum?'
<news:703nm3$o19@kiev.wall.org> {comp.lang.perl.misc}
14 Oct 1998]
%%
If UNIX is the Great American Novel, Perl is the Cliff's Notes.
[David Jacoby in `The Book is Done'
<news:70av26$462@mozo.cc.purdue.edu> {alt.sysadmin.recovery}
17 Oct 1998]
%%
In article <slrn7q2f86.fmt.abigail@alexandra.delanet.com>,
abigail@delanet.com (Abigail) writes:
: So, let's try to tie @ISA. ;-)
$abigail->reserve($hell->{'pit'}[6]); # :-)
[Greg Bacon in `OOP question',
<news:7nsb9c$n6r$2@info2.uah.edu>, {comp.lang.perl.misc}
30 July 1999]
%%
Good. If I can annoy one luser a day, my time hasn't been wasted.
[Malcomb Ray in `How can I know what modules are installed
on server?', <slrn7qgquv.46k.M.Ray@carlova.ulcc.ac.uk>,
{comp.lang.perl.misc}, 4 Aug 1999]
%%
As the length of a thread in comp.lang.perl.{misc,moderated} approaches
infinity, the probability that someone will argue with a benchmark goes
to one.
[Greg Bacon in `Bacon's Corollary to Godwin's Law'
<news:7on4s0$gtp$1@info2.uah.edu>, {comp.lang.perl.misc}
9 Aug 1999]
%%
But also, and this is the important bit, because I *couldn't have written
it* without Larry Wall giving away Perl, or Linus Torvalds handing out this
thing he was hacking on in 1991, that inspired a college sophomore in 1992
to say, "You know, this Unix thing that we've got on these here Sun boxes,
it's really nifty. Beats the shit out of Windows 3.0. And here's a way I
can get something like it on the machine in my room, for no cost."[0] Or
Ken and Dennis wanting to play games on a PDP-7 and figuring that someone
else might find their work neat. Or John Von Neumann for realizing that,
hey, here's a way to design a machine that can be almost a Universal Turing
Machine. Or Bill Shockley for figuring out that there's a neat trick you
can do to build semiconductor switches. And because I owe a lot to all
these other people whose work I'm using, it doesn't feel right to say
"Nyah! Nyah! You can't have it!" Sure, I deserve credit for what I did.
So do all the giants on whose shoulders I'm standing.
[Adam J. Thornton in `Recovery on a Monday. . .
I think. . . .' <news:7vbagi$nel$4@cnn.Princeton.EDU>
{alt.sysadmin.recovery} 29 October 1999]
%%
[On relaying email]
No it's not. It's a fundamental part of the mail system, specifically
designed into RFC821. It's there *on* *purpose*. Really. The fact that it
needs to be disabled in some cases is a result of social miscalculation
and the availability of morons with computers.
[Dan Sugalski in `sendmail deliverymode -O option'
<news:xEz34.2277$SM.8849@news.rdc1.ct.home.com>
{comp.lang.perl.misc} 8 Dec 1999]
%%
[On whether SMTP is a mail injection protocol]
Yes, it *is* a mail injection protocol. What on earth do you think Eudora,
Netscape, IE, Outlook, Pegasus Mail et al use to send mail? Carrier
pigeons?
Good grief, man, just because you like making life difficult for yourself
doesn't mean you're right.
[Dan Sugalski in `sendmail deliverymode -O option'
<news:_oz34.2272$SM.8895@news.rdc1.ct.home.com>
{comp.lang.perl.misc} 8 Dec 1999]
%%
[On whether SMTP is a mail injection protocol]
SMTP is a proper mail injection protocol. That's it's whole bloody
*point*. It wasn't hijacked, raped, coopted, or otherwise mistreated. It's
being used the way it was supposed to be used, to transfer
RFC822-compliant messages from one machine to another. Hell, in the
default config (including the one qmail uses) it's even a classic
client-server protocol. Machine connects, transfers mail to host,
disconnects.
It's been this way for ages. It's the way things were *designed*.
[Dan Sugalski in `sendmail deliverymode -O option'
<news:_Oz34.2278$SM.9018@news.rdc1.ct.home.com>
{comp.lang.perl.misc} 8 Dec 1999]
%%
If you can't debug it with vi and telnet you need a damn good reason.
["Peter da Silva" in `the trouble with logging'
<news:95ru5k$fci$1@citadel.in.taronga.com>
{bofh.general} 7 Feb 2001]
%%
The way perl does communication between processes on VMS involves mailboxes.
[Dan Sugalski in `Record I/O fix for Test.pm in older perl'
<mid:5.0.2.1.0.20010221153625.01b3d840@24.8.96.48>
{perl5-porters} 21 Feb 2001]
%%
Abigail
--
my $qr = qr/^.+?(;).+?\1|;Just another Perl Hacker;|;.+$/;
$qr =~ s/$qr//g;
print $qr, "\n";
------------------------------
Date: Tue, 6 Mar 2001 17:52:40 -0700
From: ">-\",\",\",\"P>" <patrickolson@qwest.net>
Subject: Re: PHP Help me please !!!
Message-Id: <QCfp6.1535$PA5.504345@news.uswest.net>
"calimhero" <calimhero@galbord.com> wrote in message
news:3aa4d153@kirchberg2.clt-ufa.net...
> sorry for my questions here but i don't now where ask my
question,
> i am a new developper in php and i have a question :
> i get the current month with
>
> <?
> print (date("F")) ;
> ?>
>
> and i want the next month so how to please ????????
>
>
news:php.general
news:mailing.www.php-user
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail:
php-general-unsubscribe@lists.php.net
For additional commands, e-mail:
php-general-help@lists.php.net
To contact the list administrators, e-mail:
php-list-admin@lists.php.net
Ok I caved in :)
------------------------------
Date: Tue, 06 Mar 2001 23:48:50 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: pi day
Message-Id: <taatr2pan9q5ad@corp.supernews.com>
John McNamara <jmcnamara@cpan.org> wrote:
> Ar 6 Mar 2001 07:03:41 -0000, do scriobh Jonathan Stowe
> <gellyfish@gellyfish.com>:
>>On Mon, 05 Mar 2001 16:30:14 -0000 Greg Bacon wrote:
>>> Don't forget that it's also the birthday of Albert Einstein, Billy
>>> Crystal, and noted Perl plinker Greg Bacon. Send Guinness. :-)
>>I didnt think there was an implementation of the Network Guinness Transport
>>Protocol yet.
> Guinapster anyone?
Too specialized. We need a stable, general protocol. How about
RATT? Remote Alcohol Tap Transport?
Chris
--
Christopher E. Stith
Programming is a tool. A tool is neither good nor evil. It is
the user who determines how it is used and to what ends.
------------------------------
Date: Tue, 06 Mar 2001 16:59:56 -0600
From: Michael Carman <mjcarman@home.com>
Subject: Re: RFC: FAQ3 update -- Using less memory
Message-Id: <3AA56BEC.A7F9F0CD@home.com>
Michael Carman wrote:
>
> I decided to fix [perlfaq3.17]. In the spirit of the Perl community,
> I'd appreciate any comments/additions/corrections before I submit this.
Based on the comments I've recieved so far (thanks!), here's the current
revision:
=head2 How can I make my Perl program take less memory?
When it comes to time-space tradeoffs, Perl nearly always prefers to
throw memory at a problem. Scalars in Perl use more memory than strings
in C, arrays take more than that, and hashes use even more. While
there's still a lot to be done, recent releases have been addressing
these issues. For example, as of 5.004, duplicate hash keys are shared
amongst all hashes using them, so require no reallocation.
In some cases, using substr() or vec() to simulate arrays can be
highly beneficial. For example, an array of a thousand booleans will
take at least 20,000 bytes of space, but it can be turned into one
125-byte bit vector for a considerable memory savings. The standard
Tie::SubstrHash module can also help for certain types of data
structure. If you're working with specialist data structures
(matrices, for instance) modules that implement these in C may use
less memory than equivalent Perl modules.
Another thing to try is learning whether your Perl was compiled with
the system malloc or with Perl's builtin malloc. Whichever one it
is, try using the other one and see whether this makes a difference.
Information about malloc is in the F<INSTALL> file in the source
distribution. You can find out whether you are using perl's malloc by
typing C<perl -V:usemymalloc>.
Of course, the best way to save memory is to not do anything to waste
it in the first place. Good programming practices can go a long way
toward this:
=over 4
=item * Don't slurp!
Don't read an entire file into memory if you can process it line
by line. Whenever possible, use this:
while (<FILE>) {
# ...
}
instead of this:
@data = <FILE>;
foreach (@data) {
# ...
}
and B<never> use this:
for (<FILE>) {
# ...
}
When the files you're processing are small, it doesn't much matter which
way you do it, but it makes a huge difference when they start getting
larger. The latter method keeps eating up more and more memory, while
the former method scales to files of any size.
If you do need the whole file in memory, read it directly into the data
structure where it will be used; that way you don't have multiple copies
of data clogging up RAM.
=item * Use map and grep selectively
Remember that both map and grep expect a LIST argument, so doing this:
@wanted = grep {/pattern/} <FILE>;
will cause the entire file to be slurped. For large files, it's better
to loop:
while (<FILE>) {
push(@wanted, $_) if /pattern/;
}
=item * Avoid unnecessary quotes and stringification
Don't quote large strings unless absolutely necessary:
my $copy = "$large_string";
makes 2 copies of $large_string (one for $copy and another for the
quotes), whereas
my $copy = $large_string;
only makes one copy.
Ditto for stringifying large arrays:
{
local $, = "\n";
print @big_array;
}
is much more memory-efficient than either
print join "\n", @big_array;
or
{
local $" = "\n";
print "@big_array";
}
=item * Consider using C<eval BLOCK>
If you need to initialize a large variable in your code, you
might consider doing it with an eval statement like this:
my $large_string = eval ' "a" x 5_000_000 ';
This allows perl to immediately free the memory allocated to the
eval statement, but carries a (small) performance penalty.
=item * Pass by reference
Pass arrays and hashes by reference. Perl always passes references, but
calling
foo(@array);
passes a reference to I<each element> of @array, whereas calling
foo(\@array);
passes only one reference to @array itself. This requires some
judgement, however, because any changes will be propagated back to the
original data. If you really want to mangle (er, modify) a copy, you'll
have to sacrifice the memory needed to make one.
Note: This is also the only way (sans prototyping) to pass multiple
lists and/or hashes in a single call.
=item * Tie large variables to disk.
For "big" data stores (i.e. ones that exceed available memory) consider
using one of the DB modules to store it on disk instead of in RAM. This
will incur a penalty in access time, but that's probably better that
causing your hard disk to thrash due to massive swapping.
=item * Clean out the trash
If you have a variable which consumes a large amount of RAM, you may
want to explicitly undef() once it's no longer needed. Perl might then
return the additional memory back to the OS.
=back
------------------------------
Date: Tue, 06 Mar 2001 17:00:54 -0600
From: Michael Carman <mjcarman@home.com>
Subject: Re: RFC: FAQ3 update -- Using less memory
Message-Id: <3AA56C26.2CA70A1C@home.com>
Joe Schaefer wrote:
>
> Michael Carman <mjcarman@home.com> writes:
>>
>> =item * Don't slurp!
>>
>> [...]
>
> and B<never> use this:
>
> for (<FILE>) {
> # ...
> }
Does that really hit memory harder than the explicit slurp, or is it
just ugly?
> =item * Avoid unnecessary quotes and stringification
> [...]
> Ditto for stringifying large arrays:
>
Interesting; I'd never thought about that before.
> If you need to initialize a large variable in your code, you
> might consider doing it with an eval statement like this:
>
> my $large_string = eval ' "a" x 5_000_000 ';
>
> This allows perl to immediately free the memory allocated to the
> eval statement, but carries a (small) performance penalty.
You're just full of ideas, aren't you?
>> =item * Pass by reference
>>
>> Pass arrays and hashes by reference, not by value. For one thing, it's
>> the only way
>
> (sans prototyping)
Noted.
>> to pass multiple lists or hashes (or both) in a single call/return. It
>> also avoids creating a copy of all the contents.
>
> <correction>
>
> Array elements are passed by reference, not copied
> [...]
> I think you should rework this section a bit.
Yes, I know, but I was trying to avoid having so much detail that when a
newbie checks the docs (hooray!) they can't see the forest for the
trees.
I agree it needs a little work, and will try to come up with something
better. (Accurate but concise.)
> ... If your copy consumes a large amount of RAM, you may want
> to explicitly undef() your copy once you are no longer need it. Perl
> might then return the additional memory back to the OS.
Hmm. I'd agree with you if not for what Ilya said in another branch of
this thread. It *should* help, but will it?
Thanks for your comments.
-mjc
------------------------------
Date: Wed, 07 Mar 2001 01:59:33 +0100
From: Heiko Brandhorst <Heiko.Brandhorst@gmx.de>
Subject: Set Socket to TCP_NODELAY
Message-Id: <3AA587F4.64B65419@gmx.de>
Hallo,
I use linux 7.0 and have some problems with a tcp server socket.
I want to send many small messages (40 Bytes) to a Client without delay.
But the Socket is collecting the messages up to the socket's buffer size
send them delayed.
I cannot switch off the Nagel-Algorithm which is responsible for that.
I tried:
setsockopt <Socket>, SOL_SOCKET, 1, pack( "l", 1);
setsockopt <Socket>, 0, 1, pack("l", 1); // for SOL_IP but
not defined
setsockopt <Socket> , 6, 1, pack("l", 1); // for SOL_TCP but
not defined
setsockopt <Socket>, SOL_SOCKET, SO_SNDBUF, pack("l", 40);
Any idea what's wrong, or what can i do ?
Heiko
------------------------------
Date: Wed, 07 Mar 2001 01:16:03 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Set Socket to TCP_NODELAY
Message-Id: <x7bsree5v0.fsf@home.sysarch.com>
>>>>> "HB" == Heiko Brandhorst <Heiko.Brandhorst@gmx.de> writes:
HB> I use linux 7.0 and have some problems with a tcp server socket.
HB> I want to send many small messages (40 Bytes) to a Client without
HB> delay.
HB> But the Socket is collecting the messages up to the socket's buffer size
HB> send them delayed.
how do you know that the socket layer is doing the delay? by using
PSI::ESP i can see that your socket handle is not set to autoflush and
perl is doing the buffering for you.
i have sent 1 byte over perl sockets with no delay.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
------------------------------
Date: Tue, 06 Mar 2001 23:23:14 -0000
From: Chris Stith <mischief@velma.motion.net>
Subject: Re: statement for(list);
Message-Id: <taasb2llniip09@corp.supernews.com>
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Ilmari" == Ilmari Karonen <iltzu@sci.invalid> writes:
> Ilmari> This would tie in with another item on my wish list, stacked
> Ilmari> statement modifiers:
>
> Ilmari> print if /foo/ while <>;
>
[snip]
> I asked Larry about this back in the "early days". He added this
> based on his experience with BASIC-PLUS on RSTS/E systems (which I'm
> also familiar with). When I asked him why he didn't permit nested
> modifiers as in BASIC+, he said (and I concurred) that there was *far*
> too much abuse of that in BASIC+ programs, making the programs read
> unnaturally. So he deliberately limited it to a simple expression
> modifying another simple expression for readability. If you want
> nesting, use the forward-reading block forms instead.
> So, unless Larry's changed his mind (rule #2), we won't have nested
> modifiers (rule #1). And so far, I agree with his original
> conclusion.
I'd say Larry has a good point. If you see abuse of something,
then don't allow it to be abused. Most language designers would
leave such a thing out completely for the same reason. Larry,
though, is not most language designers.
I've read quotes of Larry (I think it was Larry himself) in which
he basically says there should be more than one way to do
something, but not ten ways to do it. It seems to me what is
desirable -- to Larry, to myself, and I think to Perl programmers
as a whole -- is to have everything in the language that proves
useful in other languages, so long as they bring substantially
more usefulness than headaches.
I see where nested modifiers could be useful, but I also see where
they could bring headaches. Therefore, it should be thought out
carefully whether the usefulness is worth the headaches. To me,
probably not. Am I a usual Perl programmer? I don't know. I don't
suspect I'm that far outside the norm (no, I'm not a normal _person_,
but that's a different issue).
Chris
--
Christopher E. Stith
Even in the worst of times, there is always someone who's
never had it better. Even in the best of times, there is
always someone who's never had it worse.
------------------------------
Date: Wed, 07 Mar 2001 01:58:24 GMT
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: statement for(list);
Message-Id: <slrn9ab5e0.nts.mgjv@verbruggen.comdyn.com.au>
On 06 Mar 2001 09:10:46 -0800,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Ilmari" == Ilmari Karonen <iltzu@sci.invalid> writes:
>
>Ilmari> print if /foo/ while <>;
>Ilmari> I still think that would be cool.
>
> I asked Larry about this back in the "early days". He added this
Somewhere in the late 80's or early 90's?
> based on his experience with BASIC-PLUS on RSTS/E systems (which I'm
> also familiar with). When I asked him why he didn't permit nested
> modifiers as in BASIC+, he said (and I concurred) that there was *far*
> too much abuse of that in BASIC+ programs, making the programs read
> unnaturally. So he deliberately limited it to a simple expression
> modifying another simple expression for readability. If you want
> nesting, use the forward-reading block forms instead.
I just read Abigail's post containing some quotes from Larry. This one
seemed appropraite at this point in the discussion:
But the possibility of abuse may be a good reason for leaving
capabilities out of other computer languages, it's not a good reason
for leaving capabilities out of Perl.
[Larry Wall in `Macros'. {perl5-porters}
<199709251614.JAA15718@wall.org> 25 Sep 1997]
I happen to agree more with this quote, than with the statement your
refer to. It's also more recent.
> So, unless Larry's changed his mind (rule #2), we won't have nested
> modifiers (rule #1). And so far, I agree with his original
> conclusion.
He obviously does change his mind about some things, some times :)
Maybe we should ask.
Martien
--
Martien Verbruggen |
Interactive Media Division | "In a world without fences,
Commercial Dynamics Pty. Ltd. | who needs Gates?"
NSW, Australia |
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 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.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 431
**************************************
