[16954] in Perl-Users-Digest
Perl-Users Digest, Issue: 4366 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 18 18:25:43 2000
Date: Mon, 18 Sep 2000 15:25:29 -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: <969315929-v9-i4366@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Mon, 18 Sep 2000 Volume: 9 Number: 4366
Today's topics:
Re: Using range operator <bart.lateur@skynet.be>
Re: Using range operator <godzilla@stomp.stomp.tokyo>
Re: Using range operator <lr@hpl.hp.com>
Re: Using range operator <uri@sysarch.com>
Re: Using range operator <godzilla@stomp.stomp.tokyo>
Re: Using range operator <godzilla@stomp.stomp.tokyo>
Re: Using range operator <amonotod@netscape.net>
What's the best search script? <scanman20@hotmail.com>
Re: What's the best search script? <alian@alianwebserver.com>
Re: Why does * in a string glob? <dji@myriad.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Sep 2000 19:09:59 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: Using range operator
Message-Id: <2vpcss05i7ula2lc55jpneu4num53gvmo2@4ax.com>
Godzilla! wrote:
>A range operator is another way of saying array,
conceptually, you are right. However, recent perls (since 5.005 or
something) are optimized so that they don't atually build a 100000
element array when you say
for (1.. 10000) { ... }
See:
<http://www.perl.com/CPAN-local/doc/manual/html/pod/perldelta.html#C_foreach_1_1000000_optimize>
which is the perldelta pod for 5.005.
--
Bart.
------------------------------
Date: Mon, 18 Sep 2000 13:29:34 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Using range operator
Message-Id: <39C67B2E.F103B789@stomp.stomp.tokyo>
Bart Lateur wrote:
> Godzilla! wrote:
> > A range operator is another way of saying array,
> conceptually, you are right. However, recent perls
> (since 5.005 or something) are optimized so that they
> don't atually build a 100000 element array when you say
> for (1.. 10000) { ... }
> See:
> <http://www.perl.com/CPAN-local/doc/manual/html/pod/perldelta.html#C_foreach_1_1000000_optimize>
I posed a question in another article regarding this
"optimization" of an array constructed via a range
operator. Randal pointed out, both here and in one
of his books, at one time, arrays of this type would
eat up memory something fierce, like hogs at the
slop trough, if a range is very large numerically.
My posed question is, "What is the tradeoff?"
There is always a tradeoff of a type with something
of this nature. Nobody answered my question, which
for me is rhetorical already knowing an answer,
an answer which appears none wish to acknowledge.
"...is now optimized into a counting loop...."
Tradeoff is less use of memory but greater use
of processor time. Again, memory and time are
interchangable; they have to be. This notion
of mine contradicts what a few have stated about
memory and time are not interchangable. Clearly,
this is untrue. There is an inverse relationship,
in many cases but, as I pointed out, not in all
cases across the programming board.
As a general rule, greater use of memory usually
leads to a slower program and just the opposite,
greater processing time usually indicates a
greater use of memory. I say this based on a
premise of looking at average everyday scripts,
such as a message board, an emailer, a chat,
these types of scripts so very popular. A
larger more complex script, uses more memory
and runs slower, on an average basis.
Contrasting this general rule are our numerous
exceptions in specialty scripts. These are scripts
which have been professionally optimized to attain
a harmonious balance between memory usage and
processor time usage along with writing code
which minimizes both memory and time usage.
These are highly efficient scripts compared
to average everyday scripts.
My position, as discussed previously, is best
optimization of a typical 'range operator' type
construct, is to adamantly control the size of
your range rather than rely on perl core to
optimize this for you. Others have disagreed.
I question the quality of their logic on this.
As always, a very nice article response by
you, Mr. Lateur. This is appreciated.
Godzilla!
--
Dr. Kiralynne Schilitubi ¦ Cooling Fan Specialist
UofD: University of Duh! ¦ ENIAC Hard Wiring Pro
BumScrew, South of Egypt ¦ HTML Programming Class
------------------------------
Date: Mon, 18 Sep 2000 13:16:04 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Using range operator
Message-Id: <MPG.143017e037b087e698ad81@nntp.hpl.hp.com>
In article <7absxma8x9.fsf@merlin.hyperchip.com> on Sun, 17 Sep 2000
23:35:44 GMT, Ala Qumsieh <aqumsieh@hyperchip.com> says...
>
> Randy <randy_734@my-deja.com> writes:
>
> > Is there a simple way to use the range operator to check if a value
> > falls within?
> >
> > Something like:
> >
> > $num=5;
> > print "In range\n" if ($num == (1..20));
>
> Why do you want to use the range operator? Why not simply:
>
> print "In range" if $num >= 1 && $num <= 20;
People with a mathematical bent might find the following more
comfortable, as it looks more like the mathematical range notation:
print "In range" if 1 <= $num && $num <= 20;
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Mon, 18 Sep 2000 20:35:05 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Using range operator
Message-Id: <x7r96he8w5.fsf@home.sysarch.com>
>>>>> "G" == Godzilla! <godzilla@stomp.stomp.tokyo> writes:
G> Tradeoff is less use of memory but greater use
G> of processor time. Again, memory and time are
G> interchangable; they have to be. This notion
huh? typical bullshit from the queen of bs. you know not from memory
vs. time. shut up already.
G> of mine contradicts what a few have stated about
G> memory and time are not interchangable. Clearly,
G> this is untrue. There is an inverse relationship,
G> in many cases but, as I pointed out, not in all
G> cases across the programming board.
G> As a general rule, greater use of memory usually
G> leads to a slower program and just the opposite,
G> greater processing time usually indicates a
G> greater use of memory.
hahahahahahahah!!!
for some (stupid) definition of tradeoff.
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: Mon, 18 Sep 2000 13:50:08 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Using range operator
Message-Id: <39C68000.D7955074@stomp.stomp.tokyo>
Larry Rosler wrote:
> Ala Qumsieh wrote:
> > Randy wrote:
> > Why do you want to use the range operator? Why not simply:
> > print "In range" if $num >= 1 && $num <= 20;
> People with a mathematical bent might find the following more
> comfortable, as it looks more like the mathematical range notation:
> print "In range" if 1 <= $num && $num <= 20;
This sointly is more appealing for old peepers. Your
snippet, Mr. Rosler, has a natural 'feel' and does
comform with common practices in Mathematics.
Add some user configuration and, you have a rather
decent range checker which can be adapted for many
different usages.
print "In range" if $begin <= $num && $num <= $end;
* grins and dodges more flying rotten eggs and old brussel sprouts *
Ever eat steamed brussel sprouts? Kinda like minature heads of
cabbage and, just as silently deadly, hours later.
Godzilla!
--
Dr. Kiralynne Schilitubi ¦ Cooling Fan Specialist
UofD: University of Duh! ¦ ENIAC Hard Wiring Pro
BumScrew, South of Egypt ¦ HTML Programming Class
------------------------------
Date: Mon, 18 Sep 2000 14:01:24 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Using range operator
Message-Id: <39C682A4.5FBAD66@stomp.stomp.tokyo>
Uri Buttman blathered:
> > Godzilla! eloquently wrote with flair and style:
(snipped my wild and wicked words)
> huh? typical bullshit from the queen of bs. you
> know not from memory vs. time. shut up already.
> hahahahahahahah!!!
> for some (stupid) definition of tradeoff.
Oh my. Such an eloquent well educated and well
spoken gentleman of distinction and class! It
is rather clear, dahhhling, you are certainly
Rocket Scientist material! Are you free for
entertainment of a lady later tonight,
say around eight?
Godzilla!
--
Dr. Kiralynne Schilitubi ¦ Cooling Fan Specialist
UofD: University of Duh! ¦ ENIAC Hard Wiring Pro
BumScrew, South of Egypt ¦ HTML Programming Class
------------------------------
Date: Mon, 18 Sep 2000 21:26:50 GMT
From: amonotod <amonotod@netscape.net>
Subject: Re: Using range operator
Message-Id: <8q619v$fe1$1@nnrp1.deja.com>
In article <39C56D87.AECA7169@stomp.stomp.tokyo>,
"Godzilla!" <godzilla@stomp.stomp.tokyo> wrote:
> This reminds me of a tech ordeal I experienced just recently,
<snip>
> My final analysis was a modem was going bad at my server. This
<snip>
> A procmail program had gone rogue and would not stop running.
> With each mail sent, a new procmail instance spawned, till
> eventually, after three or four days, any perl core processing
> came to a near standstill with so many procmail spawnings. This
> very much was a mimic of a modem going bad.
<snip>
> to unavailable memory for other parallel processing.
You are just as much of an idiot now, as you were the last time I
responded to one of your posts. Anyone more intelligent than a complete
idiot would've rebooted the server, checked memory utilization, waited
awhile, then checked the memory again. Obviously, the procmail would've
shown up as multiple processes, each using it's own memory, until all
available RAM was used, then further until all SWAP was used, eventually
bringing everything to a complete halt.
You are not a technically competent person, and I have deep sympathy for
whomever you are employed by. If you work for yourself, I suggest you
hire a SysAdmin or Technician, you are in strong need of one.
> Most interesting case of slippery semantics, indeed.
No semantics, just common sense, and everyday smart (read: not book worm
intelligent) interpretation.
>
> Godzilla!
> --
> Dr. Kiralynne Schilitubi ¦ Cooling Fan Specialist
> UofD: University of Duh! ¦ ENIAC Hard Wiring Pro
> BumScrew, South of Egypt ¦ HTML Programming Class
amonotod
--
`\|||/ amonotod@
(@@) netscape.net
ooO_(_)_Ooo________________________________
_____|_____|_____|_____|_____|_____|_____|_____|
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 18 Sep 2000 19:44:22 GMT
From: scanman20 <scanman20@hotmail.com>
Subject: What's the best search script?
Message-Id: <8q5rag$7ii$1@nnrp1.deja.com>
I'm looking for recommendations on the best FREE perl search script. By
best I mean the one that has the most features, best customization, and
most accurate results. MySQL interactivity is a plus but not required.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Mon, 18 Sep 2000 23:02:59 +0200
From: Alain BARBET <alian@alianwebserver.com>
Subject: Re: What's the best search script?
Message-Id: <39C68303.7A920F8C@alianwebserver.com>
Hi,
> I'm looking for recommendations on the best FREE perl search script. By
> best I mean the one that has the most features, best customization, and
> most accurate results. MySQL interactivity is a plus but not required.
I don't know if it is the best, but it work and do what you want:
http://www.alianwebserver.com/circa,
PS: If you see big mistake at this url in my english, thank you to give
me feedback !
HTH,
--
Alain & Estelle BARBET
------------------------------
Date: Mon, 18 Sep 2000 15:21:58 -0600
From: David J Iannucci <dji@myriad.com>
Subject: Re: Why does * in a string glob?
Message-Id: <39C68776.3702260@myriad.com>
Martien Verbruggen wrote:
> How do you get that string to your database? Any invocations of shell
> with system(), backticks and/or qx//? Perl certainly will not glob a *
> in a doublequoted string unless you ask for it explicitly.
Nope, none of these. The database is Sybase ASE 11.5 and I'm using
SybPerl (Sybase::DBlib) for database access from Perl.
I'll check a little deeper and see what I can find, and will consult
SybPerl's mailing list. I was hoping there'd be a straightforward
answer related to Perl :-)
Thanks for the advice.
And to the gentleman who suggested I do perl -w to find where I
had made a typo, I'm happy to say that this reveals no problem at
all :-)
Dave Iannucci
Myriad Genetics, Inc.
dji@myriad.com
------------------------------
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 V9 Issue 4366
**************************************
