[25313] in Perl-Users-Digest
Perl-Users Digest, Issue: 7558 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 23 00:05:37 2004
Date: Wed, 22 Dec 2004 21:05:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 22 Dec 2004 Volume: 10 Number: 7558
Today's topics:
[OT] Re: Good practice to detect empty string? <1usa@llenroc.ude.invalid>
Re: Basic CGI.pm question <matthew.garrish@sympatico.ca>
Re: generating a session id <joe@inwap.com>
Re: generating a session id <joe@inwap.com>
Re: Good practice to detect empty string? <jl_post@hotmail.com>
Re: Good practice to detect empty string? <uri@stemsystems.com>
Re: Good practice to detect empty string? <joe@inwap.com>
Re: Good practice to detect empty string? <jl_post@hotmail.com>
Re: Good practice to detect empty string? <jl_post@hotmail.com>
Re: Good practice to detect empty string? <jurgenex@hotmail.com>
How can script find its host's name/IP address? <socyl@987jk.com.invalid>
Re: How can script find its host's name/IP address? <socyl@987jk.com.invalid>
Re: How can script find its host's name/IP address? <1usa@llenroc.ude.invalid>
Re: How can script find its host's name/IP address? <matthew.garrish@sympatico.ca>
How to redirect my $fh to STDOUT? <please_post@nomail.edu>
Re: How to redirect my $fh to STDOUT? <1usa@llenroc.ude.invalid>
Re: Is zero even or odd? <jfields@austininstruments.com>
Re: Output pipes xhoster@gmail.com
Reinitializing Size of Anonymous Array <ihatespam@hotmail.com>
Re: Reinitializing Size of Anonymous Array <1usa@llenroc.ude.invalid>
Re: retrieving Hash elements <amead@comcast.net>
Re: retrieving Hash elements <nospam@nospam.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 23 Dec 2004 02:52:05 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: [OT] Re: Good practice to detect empty string?
Message-Id: <Xns95C7DE7529F45asu1cornelledu@132.236.56.8>
"jl_post@hotmail.com" <jl_post@hotmail.com> wrote in
news:1103768267.436349.25850@f14g2000cwb.googlegroups.com:
> Uri Guttman wrote:
>
>> <snip of overly massive tome on this subject>
>>
>> jpc> This quote is widely attributed to Donald Knuth:
>> jpc> "Premature optimization is the root of all evil."
>>
>> why didn't you just say that and cut out most of the rest (including
>> your comments on how length works in perl)?
...
> By the way the original poster posted his message, he seemed to
> think that the faster method was good while all the rest were bad! He
> may have obtained this notion the same way I did: when a computer
> science professor gave a lecture on operations and how expensive they
> are and how they ultimately cost money.
I can why Jean-Luc responded the way he did (it was a little long for my
taste though :)
I have seen people attempt to find the least cost path through a graph with
a bazillion edges by first enumerating all the possible paths. They even
react by not believing the simple calculations that prove their program
will have to run for eons before it can ever come up with an answer. The
same people tend to also be overly impressed with obscure optimization
tricks.
That makes anyone who wants to optimize the following a little suspect and
possibly in need of some advice.
my $var;
# ...
$var = 'default' unless defined $var and length $var;
--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)
------------------------------
Date: Wed, 22 Dec 2004 18:16:38 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Basic CGI.pm question
Message-Id: <ofnyd.26553$GK5.1272949@news20.bellglobal.com>
"Will Hartung" <willh@msoft.com> wrote in message
news:32tqeqF3r491uU1@individual.net...
> Hi all,
>
> I was trying to write a simple CGI script last night and ran in to some
> issues.
>
> use CGI;
>
> my $query = new CGI;
> my $vars = $query->Vars;
> my $elements;
> my $combined;
>
> $elements{abc} = "123";
> $elements{xyz} = "qed";
>
> %combined = (%elements, %vars);
>
> print %combined;
>
Your issue doesn't appear to be with CGI.pm, but with a lack of
understanding of Perl data structures. It's not surprising that you're
getting nothing from the command line, since you store the reference to
those variables in $vars, but then try and access %vars.
This is exactly the reason why you should start all scripts with:
use strict;
use warnings;
Matt
------------------------------
Date: Wed, 22 Dec 2004 18:02:38 -0800
From: Joe Smith <joe@inwap.com>
Subject: Re: generating a session id
Message-Id: <BoGdnULNn4DdulfcRVn-3w@comcast.com>
ioneabu@yahoo.com wrote:
> for (my $i=0;$i<$length;$i++) {$out .= $array[rand(36)]}
>
> The first method is from Apache:Session:MySQL. Why is it any better
> than my version for generating a random 32 character string?
The rand() function does not have an infinite supply of bits.
It will start repeating after a while. A 32-bit algorithm has
a little over 4 billon bit patterns, which does not cover the
full gamut of 9 base-36 characters.
I expect that by the time you get to the 10th character, the
remaining characters of your method are predictable and not random.
-Joe
------------------------------
Date: Wed, 22 Dec 2004 18:08:31 -0800
From: Joe Smith <joe@inwap.com>
Subject: Re: generating a session id
Message-Id: <jbCdnef2bsg_tVfcRVn-oA@comcast.com>
ioneabu@yahoo.com wrote:
> I have made an effort to understand a process by exploring it in its
> most basic form, as if I had to create for the first time. Of course
> my simple minded code is not as good as the real thing, but why?
When I connect to your server and get a session ID using your algorithm,
with not too much effort I can determine the current seed of your rand()
function. With that knowledge, I could predict what the next session ID
is going to be, and start hijacking your customer's sessions.
Your method has insufficent entropy and is not of cryptographic quality.
-Joe
------------------------------
Date: 22 Dec 2004 15:19:40 -0800
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Good practice to detect empty string?
Message-Id: <1103757580.548429.304980@c13g2000cwb.googlegroups.com>
ipellew@pipemedia.co.uk wrote:
>
> I am using
> if ( $@ || $c_var eq "" ) {
> but constantly read `eq` is expensive.
>
> For example is
> if ( $@ || ! length $c_var ) {
> better, faster, cheaper
Dear Ian,
I'm not convinced that $var eq "" is necessarily more expensive
than length($var) . The reason I think this is because the eq
operator can report a false value as soon as it detects a character in
the variable it is examining, whereas the length() function must count
every single character in $var, even if $var is millions of characters
long.
The method that is more expensive really depends on the
implementation of the two functions/operators. If you really want to
know which one is more expensinve for the task at hand, use the
Benchmark module (read "perldoc Benchmark" to find out how to use it).
But to be honest, it really doesn't matter which method is better,
faster, cheaper. They are pretty much the same in terms of efficiency.
Sure, one may use up a few more clock cycles than the other, but this
is a small constant value that is practically imperceptable, even by
computer standards (in fact, when I got used the Benchmark module I saw
the warning: "(warning: too few iterations for a reliable count)" even
when I used a count of ten million).
A lot of programmers fall into the trap of thinking that if they
always use the faster, more efficient operators that their code will
run much faster than before. This is true only if the algorithms used
in these options behave better with large data (are you familiar with
Big-O notation?). So if your program can't handle large amounts of
data very well (that is, if it had a Big-O value of N-squared), simply
converting all your '$val eq ""' conditions to '!length($val)' isn't
going to make your program magically handle large amounts of data.
That's because eq and length() have roughly the same Big-O value. To
make your program run faster, you'd have to modify its algorithms so
that none of them are N-squared (or worse). At this point, the use of
eq versus length() is really a moot point.
To illustrate, if using the length() function is one-millionth of a
second faster than using eq, it will only make a noticeable difference
if length() (or eq) is used (on the order of) one million times more
often than anything else (and then, the difference might only be one
second). That is, if you want to check for the existence of an empty
string only five, one hundred, or even a thousand times in your code,
it really won't make a difference whether you use eq or length().
Theoretically, one method will be faster than the other, but you
couldn't time this difference with a stopwatch, even if you had faster
reflexes than anybody else in the world. And like I mentioned above,
even Perl's Benchmark module has trouble perceiving this time
difference.
In my opinion, you should usually use the function/operation that is
more readable (and, of course, you have to decide for yourself which is
more readable). If you spend two minutes converting the code to
something that is theoretically faster, you might not even save one
second of total running time (from every time you run the program).
And if it takes someone in the future three extra minutes to figure out
what you were trying to do, that's more than four minutes and 59
seconds wasted changing your code, thinking that your code will become
faster, better, cheaper.
I realize I wrote a lot about this subject, but to summarize, let me
say this:
Making code run faster almost always means eliminating the
bottlenecks. Changing '$var eq ""' to '!length($var)' might make a
difference (probably super small) but it won't eliminate a bottleneck.
Here is a real-world analogy (if you like these kinds of things):
There is a ten-mile-long road that people drive their cars on. Most
of this road has two lanes. But for some reason, five miles along the
road, the two lanes merge into one lane, but only for 100 meters (after
which they become two lanes again).
Ordinarily this isn't a problem when there are few cars on the road.
As a car reaches the place where the two lanes become one, it switches
lanes (if needed), and then switches back when there are two lanes
again.
But during periods of heavy traffic, this lane merge causes a
bottleneck. Multiple cars are trying to squeeze into one lane at the
same time, creating a bottleneck and backing up traffic for miles.
This is unacceptable, and a solution must be found.
Someone might say that the speed limit should be raised from 55 mph
to 60 mph, because 60 mph is faster, and therefore more efficient, and
will make the cars move faster. Another person might say to make the
stretch of road that only has one lane shorter so that there is more of
the road with two full lanes.
Their intentions are good, but none of these solutions eliminate the
bottleneck, which is what is slowing down traffic. A solution that is
much better than either of those just listed would be to insert a
second lane (where there is currently only one lane) for cars to use
instead of having to merge. (In fact, you could even reduce the speed
limit to 50 mph with this solution and it would still work better than
the solution to only raise the speed limit to 60 mph!)
And while raising the speed limit to 60 mph sounds good, it won't
even save you a full minute when the bottleneck is present. With the
bottleneck, the traffic might be backed up for hours, so just
eliminating one minute won't make all that much difference. Eliminate
the bottleneck and hours of driving time will be saved, even when the
speed limit is significantly slower.
And that's why I think you shouldn't worry about whether you should
use eq or length(). Just go with the one that is more readable and
easier to maintain and understand, and you will end up saving more time
in the future by not having to figure some possibly convoluted code
that might not make much difference in the end at all.
This quote is widely attributed to Donald Knuth:
"Premature optimization is the root of all evil."
The point of the quote is that if you try to optimize a section of code
before you can prove that it needs to be optimized, you may end up
writing obfuscated, difficult-to-read code for nothing.
I hope this helps, Ian.
-- Jean-Luc Romano
------------------------------
Date: Wed, 22 Dec 2004 23:37:00 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Good practice to detect empty string?
Message-Id: <x7wtv9dhwk.fsf@mail.sysarch.com>
>>>>> "jpc" == jl post@hotmail com <jl_post@hotmail.com> writes:
jpc> I'm not convinced that $var eq "" is necessarily more expensive
jpc> than length($var) . The reason I think this is because the eq
jpc> operator can report a false value as soon as it detects a character in
jpc> the variable it is examining, whereas the length() function must count
jpc> every single character in $var, even if $var is millions of characters
jpc> long.
why must length count all the chars? how will it know when the string
ends? does the string end in a zero byte? but perl strings can have any
binary data? so how does perl figure out the length of strings? hmmm.
<snip of overly massive tome on this subject>
jpc> This quote is widely attributed to Donald Knuth:
jpc> "Premature optimization is the root of all evil."
jpc> The point of the quote is that if you try to optimize a section of code
jpc> before you can prove that it needs to be optimized, you may end up
jpc> writing obfuscated, difficult-to-read code for nothing.
jpc> I hope this helps, Ian.
why didn't you just say that and cut out most of the rest (including
your comments on how length works in perl)?
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Wed, 22 Dec 2004 18:13:31 -0800
From: Joe Smith <joe@inwap.com>
Subject: Re: Good practice to detect empty string?
Message-Id: <jbCdneb2bshWtFfcRVn-oA@comcast.com>
jl_post@hotmail.com wrote:
> I'm not convinced that $var eq "" is necessarily more expensive
> than length($var) . The reason I think this is because the eq
> operator can report a false value as soon as it detects a character in
> the variable it is examining, whereas the length() function must count
> every single character in $var
Perl's length() function does not count characters.
The information is already present in the guts of a scalar value.
Therefore your reasoning is incorrect.
-Joe
------------------------------
Date: 22 Dec 2004 18:17:47 -0800
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Good practice to detect empty string?
Message-Id: <1103768267.436349.25850@f14g2000cwb.googlegroups.com>
Uri Guttman wrote:
>
> why must length count all the chars? how will it know
> when the string ends? does the string end in a zero
> byte? but perl strings can have any binary data? so
> how does perl figure out the length of strings? hmmm.
Hmmm... I didn't think of that. You bring up a good point.
Reflecting on what you just said, I'm remembering the Devel::Peek
module. The Devel::Peek::Dump() function lists a string's length, so
I'm guessing that the length() function could probably get that
attribute from the same place that Devel::Peek::Dump() does.
Thanks for pointing that out.
> <snip of overly massive tome on this subject>
>
> jpc> This quote is widely attributed to Donald Knuth:
> jpc> "Premature optimization is the root of all evil."
>
> why didn't you just say that and cut out most of the rest (including
> your comments on how length works in perl)?
Since you asked, I'll explain.
This subject has come up several times with my peers, and I'm still
amazed what some programmers will favor in the name of efficiency and
speed. For example, some people will refuse to ever use the line:
$i++;
when $i is just an integer. Instead, they will say the code is wrong
unless it is written as:
++$i;
or:
$i += 1;
The reason they think that using the post-increment operator is wrong
is because it makes an extra copy that is never used (which is slower
and less efficient).
Now, they might have a point if $i is a blessed reference pointing
to a huge structure, but when $i is just an integer, it won't save you
any noticeable difference to use pre-increment instead of
post-increment.
But I've had people challenge me on this. They say that if you're
writing code, it should be as efficient as possible because it could
get called in a very tight loop that gets called a large number of
times.
And while I agree that code should be efficient, I point out that if
the code they write is running slowly, changing a post-increment
operator to a (presumably faster) pre-decrement operator isn't going to
speed up the program any satisfiable (or noticeable) amount. What will
make the difference instead is to re-write any algorithms with a Big-O
notation of N-squared (or worse) to be ones that have a Big-O notation
of N log(N) (or better).
And no matter how many times I try to convince them that a
bottleneck won't be eliminated just by replaceing something as trivial
as a post-increment operator with a pre-decrement operator, the person
I'm talking with often ends the discussion with: "Well... I'm still
going to use the more efficient code." Unfortunately, all too often
that means that their code will be more difficult to read and
understand (for others, of course), especially when they omit comments
explaining what their code is attempting to do and why it was written
that way. And often, their "more efficient" code is more bug-prone
than the equivalent "inferior, inefficient" code.
It seemed like you understood my point. But a lot of people don't.
They hear a cute little quote like this one I read from
http://www-106.ibm.com/developerworks/library/l-optperl.html :
> All of this help, though, comes at a slight performance
> cost. I keep warnings and strict on while programming
> and debugging, and I switch it off once the script is
> ready to be used in the real world. It won't save much,
> but every millisecond counts.
I totally disagree with this (I won't go into the reasons why). But my
point is that many people will read this and use this as their
manifesto not to use warnings and strict.
I can counteract with another cute quote, but I've found that if a
person has been swayed by a cute-sy quote, they generally won't get
swayed back by another.
By the way the original poster posted his message, he seemed to
think that the faster method was good while all the rest were bad! He
may have obtained this notion the same way I did: when a computer
science professor gave a lecture on operations and how expensive they
are and how they ultimately cost money.
To answer your question, one quote alone is usually not enough to
sway a person's beliefs, so I felt the need to back it up with a
real-world example and scenario in the hopes that it would educate the
original poster.
I didn't mean to offend you or any other poster on this newsgroup
with my long response, but it's a pet peeve of mine when others write
obsfuscated code in the name of efficiency, particularly when the
amount of time saved from the total run-times of every run of the
"efficient" program amounts to less than a second. That's why I felt
that a thorough response was in order.
I hope this makes sense, Uri. (And thanks for pointing out that
thing about using length().)
-- Jean-Luc
------------------------------
Date: 22 Dec 2004 18:23:30 -0800
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Good practice to detect empty string?
Message-Id: <1103768610.873268.65380@z14g2000cwz.googlegroups.com>
Joe Smith wrote:
>
> Perl's length() function does not count characters.
> The information is already present in the guts of a
> scalar value. Therefore your reasoning is incorrect.
I see I was wrong. Thanks for pointing that out.
I realized later that I could see this information by using the
Devel::Peek module, like this:
> perl -MDevel::Peek -e "Dump('perl')"
SV = PV(0x225208) at 0x1823e98
REFCNT = 1
FLAGS = (PADBUSY,PADTMP,POK,READONLY,pPOK)
PV = 0x182ac34 "perl"\0
CUR = 4
LEN = 5
Again, thanks.
-- Jean-Luc
------------------------------
Date: Thu, 23 Dec 2004 03:45:09 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Good practice to detect empty string?
Message-Id: <9bryd.1491$1U6.1091@trnddc09>
jl_post@hotmail.com wrote:
> This subject has come up several times with my peers, and I'm still
> amazed what some programmers will favor in the name of efficiency and
> speed. For example, some people will refuse to ever use the line:
>
> $i++;
>
> when $i is just an integer. Instead, they will say the code is wrong
> unless it is written as:
>
> ++$i;
>
> or:
>
> $i += 1;
>
> The reason they think that using the post-increment operator is wrong
> is because it makes an extra copy that is never used (which is slower
> and less efficient).
Tell them to take a class in basic compiler construction. Well, compile time
optimizations are an advanced topic, so they will have to take two classes.
But any compiler, that does not fold all three statements into the most
efficient form is not worth its money, even if it's free.
jue
------------------------------
Date: Thu, 23 Dec 2004 02:54:13 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: How can script find its host's name/IP address?
Message-Id: <cqdc0l$4dd$1@reader1.panix.com>
How can script find the hostname (or at least the IP address) of
the host it is running on?
TIA,
kj
------------------------------
Date: Thu, 23 Dec 2004 03:03:36 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: How can script find its host's name/IP address?
Message-Id: <cqdci8$4hg$1@reader1.panix.com>
In <cqdc0l$4dd$1@reader1.panix.com> kj <socyl@987jk.com.invalid> writes:
>How can script find the hostname (or at least the IP address) of
>the host it is running on?
Sorry, I shouldn't have written "hostname"; what I want is the full
hostname+domainname combination, as in foo.bar.com (as opposed to
just foo).
Also, I should have mentioned that I looked at the Perl FAQ, but
didn't get a satisfactory answer to my question. The Perl FAQ does
include a question on how to get the "hostname/domainname/IP
address", but it doesn't really answer the question of how to get
the domainname. It only explains how to get the hostname and the
IP address. It gives advice on how to get the name of the local
DNS server, but says nothing on how that script would use this
information to obtain the host's domainname.
kj
------------------------------
Date: 23 Dec 2004 03:07:21 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: How can script find its host's name/IP address?
Message-Id: <Xns95C7E10B8908Basu1cornelledu@132.236.56.8>
kj <socyl@987jk.com.invalid> wrote in
news:cqdci8$4hg$1@reader1.panix.com:
> In <cqdc0l$4dd$1@reader1.panix.com> kj <socyl@987jk.com.invalid>
> writes:
>
>
>>How can script find the hostname (or at least the IP address) of
>>the host it is running on?
>
>
> Sorry, I shouldn't have written "hostname"; what I want is the full
> hostname+domainname combination, as in foo.bar.com (as opposed to
> just foo).
>
> Also, I should have mentioned that I looked at the Perl FAQ, but
> didn't get a satisfactory answer to my question.
How about CPAN?
http://tinyurl.com/5epvm
--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)
------------------------------
Date: Wed, 22 Dec 2004 22:06:52 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: How can script find its host's name/IP address?
Message-Id: <eDqyd.27938$GK5.1356247@news20.bellglobal.com>
"kj" <socyl@987jk.com.invalid> wrote in message
news:cqdc0l$4dd$1@reader1.panix.com...
>
> How can script find the hostname (or at least the IP address) of
> the host it is running on?
>
The same way you'd do it in any other language: read the environment
variables.
Matt
------------------------------
Date: Thu, 23 Dec 2004 02:10:08 +0000 (UTC)
From: bill <please_post@nomail.edu>
Subject: How to redirect my $fh to STDOUT?
Message-Id: <cqd9e0$3i4$1@reader1.panix.com>
I'm debugging a script not written by me, and having a rough time
of it (it is a huge script with no subroutines; uses no modules;
etc.). Near the top of the file (i.e. near the beginning of this
script's execution), a lexical filehandle is opened for writing,
and remains open throughout. It would be useful if I could redirect
this lexical filehandle to STDOUT. I've read the docs on "duplicating"
filehandles, but I confess that I don't quite understand them.
Could someone show me how I'd redirect an open lexical write handle
from a file to STDOUT?
Thanks!
bill
------------------------------
Date: 23 Dec 2004 02:32:01 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: How to redirect my $fh to STDOUT?
Message-Id: <Xns95C7DB0E387FFasu1cornelledu@132.236.56.8>
bill <please_post@nomail.edu> wrote in news:cqd9e0$3i4$1
@reader1.panix.com:
> I'm debugging a script not written by me, and having a rough time
> of it (it is a huge script with no subroutines; uses no modules;
> etc.).
Good luck.
> Near the top of the file (i.e. near the beginning of this
> script's execution), a lexical filehandle is opened for writing,
> and remains open throughout. It would be useful if I could redirect
> this lexical filehandle to STDOUT.
Would the following do what you want?
#! perl
use strict;
use warnings;
# open my $fh, '>', 'somefile' or die $!;
my $fh = \*STDOUT;
print $fh "This should print to STDOUT\n";
--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)
------------------------------
Date: Wed, 22 Dec 2004 17:50:54 -0600
From: John Fields <jfields@austininstruments.com>
Subject: Re: Is zero even or odd?
Message-Id: <anujs01po9v92ocvorbp3dsi8ohq1i5bql@4ax.com>
On Wed, 22 Dec 2004 22:26:49 GMT, "Nicholas O. Lindan" <see@sig.com>
wrote:
>John Fields wrote:
>> OXO
>> -
>> |.
>> | .
>> | .
>> | .
>> --.------0,0--------
>> . |
>> . |
>> . |
>> .|
>> -
>>
>> -
>> |
>> OXO
>
>
>One infinity, one zero. +oo == -oo; +0 == -0. Neither
>actually exist and you can approach from the direction of
>your choice.
>
>From the graph I would say 1/0 is oo.
---
Seems to make sense, doesn't it?
---
>Somebody wrote a whole book on '0', I have (had?) a copy
>but darned if I can find it.
---
I got a book on 'e', but every time I go looking for it it takes me
just as long to find it as it took the time before that, even if I
start looking for it where I left it. :^)
--
John Fields
------------------------------
Date: 23 Dec 2004 00:26:08 GMT
From: xhoster@gmail.com
Subject: Re: Output pipes
Message-Id: <20041222192608.601$3f@newsreader.com>
Kim Helliwell <kimgh@pacbell.net> wrote:
> Once again, forgive the imprecision. I guess I should have included
> the context from my original post as well.
>
> I'm piping output from a Perl script to xgraph, which is an X-windows
> graphing application (that is, it has a GUI). So when xgraph starts,
> it doesn't quit until I mouse-click to close it. And, the script blocks
> until that happens. Clear so far?
Sorry, still not clear. At what point in your script is it blocking?
upon the open of the file handle piped to xgraph? Upon any print to that
file handle? Upon printing over a certain number of bytes to that file
handle? Upon closing that file handle?
I don't see any reason it should block (for more than a brief time) at any
stage except the closing part. In which case, not closing the handles
would be one solution!
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Wed, 22 Dec 2004 20:24:54 -0800
From: BigDaDDY <ihatespam@hotmail.com>
Subject: Reinitializing Size of Anonymous Array
Message-Id: <10ski0msvpn676c@corp.supernews.com>
How would I reinitialize the size of an anonymous array? For example:
foreach $run (@runs){
push (@{$table{$country}}), $city
}
However, for each run, I want to clear the array. I've seen the
$#array = -1 to clear a regular array, but not quite sure what to do hear.
Any help would be highly appreciated. Thanks,
Matt
------------------------------
Date: 23 Dec 2004 04:42:37 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Reinitializing Size of Anonymous Array
Message-Id: <Xns95C7F13259A87asu1cornelledu@132.236.56.8>
BigDaDDY <ihatespam@hotmail.com> wrote in
news:10ski0msvpn676c@corp.supernews.com:
> How would I reinitialize the size of an anonymous array? For example:
>
>
> foreach $run (@runs){
>
> push (@{$table{$country}}), $city
> }
>
> However, for each run, I want to clear the array. I've seen the
> $#array = -1 to clear a regular array, but not quite sure what to do
> hear.
What is your real question?
use strict;
use warnings;
use Data::Dumper;
my %hash;
for my $run (1 .. 10) {
$hash{list} = [ ];
for my $i (1 .. 10) {
push @{ $hash{list} }, $i;
}
print Dumper \%hash;
sleep 5;
}
--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)
------------------------------
Date: Wed, 22 Dec 2004 21:32:43 -0600
From: Alan Mead <amead@comcast.net>
Subject: Re: retrieving Hash elements
Message-Id: <pan.2004.12.23.03.32.41.883997@comcast.net>
Star date: Wed, 22 Dec 2004 12:42:27 -0500, daniel kaplan's log:
> Was trying to see if there is a way to retrieve hash keys in the order they
> were created? Which I have not found in any of my books or perldoc. I
Daniel,
Others have given you your answer. I just wanted to add that if you have
the Perl Cookbook, this is recipe 5.7 (in the 2ND ED). If you don't have
this book, I recommend that you buy it. A very large percentage of my
questions are either answered directly or else I am given a good clue.
Studying the code also has a lot of practical instructional value...
-Alan
------------------------------
Date: Wed, 22 Dec 2004 23:37:54 -0500
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: retrieving Hash elements
Message-Id: <1103776646.431694@nntp.acecape.com>
"Alan Mead" <amead@comcast.net> wrote in message
news:pan.2004.12.23.03.32.41.883997@comcast.net...
> Star date: Wed, 22 Dec 2004 12:42:27 -0500, daniel kaplan's log:
>
> Others have given you your answer. I just wanted to add that if you have
> the Perl Cookbook, this is recipe 5.7 (in the 2ND ED). If you don't have
> this book, I recommend that you buy it. A very large percentage of my
> questions are either answered directly or else I am given a good clue.
> Studying the code also has a lot of practical instructional value...
>
thank you very much...will make sure i go and check it out!
------------------------------
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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 7558
***************************************
