[30162] in Perl-Users-Digest
Perl-Users Digest, Issue: 1405 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 30 00:09:41 2008
Date: Sat, 29 Mar 2008 21:09:07 -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 Sat, 29 Mar 2008 Volume: 11 Number: 1405
Today's topics:
Re: BEGIN, INIT etc... <nospam-abuse@ilyaz.org>
Re: BEGIN, INIT etc... <ben@morrow.me.uk>
Re: BEGIN, INIT etc... <joost@zeekat.nl>
Re: BEGIN, INIT etc... <ben@morrow.me.uk>
Re: BEGIN, INIT etc... <joost@zeekat.nl>
Re: BEGIN, INIT etc... <ben@morrow.me.uk>
Re: BEGIN, INIT etc... <joost@zeekat.nl>
Re: BEGIN, INIT etc... <szrRE@szromanMO.comVE>
Re: BEGIN, INIT etc... <joost@zeekat.nl>
Re: Memory issues <jm@nospam.fr>
Re: Memory issues <smallpond@juno.com>
Re: Memory issues <jm@nospam.fr>
Re: Memory issues <joost@zeekat.nl>
NIC Configurations <XXjbhuntxx@white-star.com>
Perl-10: solaris; how to run configure with NO asks, bu (David Combs)
Re: Perl-10: solaris; how to run configure with NO asks <ben@morrow.me.uk>
Re: Readline using foreach and while <szrRE@szromanMO.comVE>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 29 Mar 2008 20:49:31 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: BEGIN, INIT etc...
Message-Id: <fsma0r$gmc$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Bart Lateur
<bart.lateur@pandora.be>], who wrote in article <okgsu3tlkqhr7n9ha0tf0d0m0k01n9lf4b@4ax.com>:
> Joost Diepenmaat wrote:
>
> >END blocks are useful to "guarantee" that code gets run when the program
> >ends, even if for example an exception is thrown. Useful for system
> >resources that may not get freed properly otherwise.
>
> Unfortunately they're still not called on exit and on exec.
You mean "Fortunately they are not called on _exit(); do not forget to
never use exec()"?
[END() IS called on exit(). Signal handlers can be installed to die()
on signal, so END() is called on signals.]
Hope this helps,
Ilya
------------------------------
Date: Sat, 29 Mar 2008 22:30:37 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: BEGIN, INIT etc...
Message-Id: <dhs2c5-lk6.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> [A complimentary Cc of this posting was sent to
> Bart Lateur
> <bart.lateur@pandora.be>], who wrote in article
> <okgsu3tlkqhr7n9ha0tf0d0m0k01n9lf4b@4ax.com>:
> > Joost Diepenmaat wrote:
> >
> > >END blocks are useful to "guarantee" that code gets run when the program
> > >ends, even if for example an exception is thrown. Useful for system
> > >resources that may not get freed properly otherwise.
> >
> > Unfortunately they're still not called on exit and on exec.
>
> You mean "Fortunately they are not called on _exit();
Well, no, that's kind-of the point...
> do not forget to never use exec()"?
I am confused. How is one (on a fork/exec-based system, or perl's
emulation of such under Win32) supposed to avoid calling exec when
necessary?
> [END() IS called on exit(). Signal handlers can be installed to die()
> on signal, so END() is called on signals.]
END blocks are not called when a process exits because of the DEFAULT
action of a signal. It is of course possible to fix this by installing
an appropriate signal handler.
Ben
------------------------------
Date: Sat, 29 Mar 2008 23:45:22 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: BEGIN, INIT etc...
Message-Id: <87k5jl2lq5.fsf@zeekat.nl>
Ben Morrow <ben@morrow.me.uk> writes:
> I am confused. How is one (on a fork/exec-based system, or perl's
> emulation of such under Win32) supposed to avoid calling exec when
> necessary?
By using fork(), ofcourse! Am I missing something?
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 30 Mar 2008 00:56:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: BEGIN, INIT etc...
Message-Id: <o353c5-qa7.ln1@osiris.mauzo.dyndns.org>
Quoth Joost Diepenmaat <joost@zeekat.nl>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > I am confused. How is one (on a fork/exec-based system, or perl's
> > emulation of such under Win32) supposed to avoid calling exec when
> > necessary?
>
> By using fork(), ofcourse! Am I missing something?
Err... yes? fork creates a clone of the current process, exec changes
which file the current process is executing. Any method of executing an
external program, on Unix, ends up calling exec.
Ben
------------------------------
Date: Sun, 30 Mar 2008 03:39:21 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: BEGIN, INIT etc...
Message-Id: <87fxu9j8hi.fsf@zeekat.nl>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Joost Diepenmaat <joost@zeekat.nl>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> > I am confused. How is one (on a fork/exec-based system, or perl's
>> > emulation of such under Win32) supposed to avoid calling exec when
>> > necessary?
>>
>> By using fork(), ofcourse! Am I missing something?
>
> Err... yes? fork creates a clone of the current process, exec changes
> which file the current process is executing. Any method of executing an
> external program, on Unix, ends up calling exec.
But for the purposes of END blocks, using fork() before an exec() would
allow the END blocks to run anyway:
# simplified:
END {
# clean up stuff here
# assuming close-on-exec & equivalents are correctly set
}
if (! fork()) { # assumin fork() doesn't fail here.
exec $whatever;
exit;
}
exit;
This is assuming the fork() or exec() themselves won't introduce new
issues.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 30 Mar 2008 02:55:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: BEGIN, INIT etc...
Message-Id: <0h83c5-ok7.ln1@osiris.mauzo.dyndns.org>
Quoth Joost Diepenmaat <joost@zeekat.nl>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > Quoth Joost Diepenmaat <joost@zeekat.nl>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >>
> >> > I am confused. How is one (on a fork/exec-based system, or perl's
> >> > emulation of such under Win32) supposed to avoid calling exec when
> >> > necessary?
> >>
> >> By using fork(), ofcourse! Am I missing something?
> >
> > Err... yes? fork creates a clone of the current process, exec changes
> > which file the current process is executing. Any method of executing an
> > external program, on Unix, ends up calling exec.
>
> But for the purposes of END blocks, using fork() before an exec() would
> allow the END blocks to run anyway:
Sorry, I misunderstood you. Yes, that will work, of course.
> # simplified:
>
> END {
> # clean up stuff here
> # assuming close-on-exec & equivalents are correctly set
> }
>
> if (! fork()) { # assumin fork() doesn't fail here.
> exec $whatever;
> exit;
You need POSIX::_exit here, or the END blocks get run twice (once for
each process).
> }
> exit;
You probably want to wait here before exitting, as otherwise the execed
process is orphaned, and your parent gets SIGCHLD early. You probably
also want to set up signal handlers to pass signals along, etc... see
the source for the shell of your choice :). Or you could just use
system, which does all that for you.
Ben
------------------------------
Date: Sun, 30 Mar 2008 04:07:21 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: BEGIN, INIT etc...
Message-Id: <87myohge1y.fsf@zeekat.nl>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Joost Diepenmaat <joost@zeekat.nl>:
>> if (! fork()) { # assumin fork() doesn't fail here.
>> exec $whatever;
>> exit;
>
> You need POSIX::_exit here, or the END blocks get run twice (once for
> each process).
Sorry, that's my mistake: exec() never returns, unless it fails, and I
tried to disregard every complication to make the point.
>> }
>> exit;
>
> You probably want to wait here before exitting, as otherwise the execed
> process is orphaned, and your parent gets SIGCHLD early. You probably
> also want to set up signal handlers to pass signals along, etc... see
> the source for the shell of your choice :). Or you could just use
> system, which does all that for you.
Sure, this is just the extremely simplified version :-)
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sat, 29 Mar 2008 19:10:47 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: BEGIN, INIT etc...
Message-Id: <fsmsr802tu4@news2.newsguy.com>
Ben Morrow wrote:
> Quoth Joost Diepenmaat <joost@zeekat.nl>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>>> Quoth Joost Diepenmaat <joost@zeekat.nl>:
>>>> Ben Morrow <ben@morrow.me.uk> writes:
>>>>
>>>>> I am confused. How is one (on a fork/exec-based system, or perl's
>>>>> emulation of such under Win32) supposed to avoid calling exec when
>>>>> necessary?
>>>>
>>>> By using fork(), ofcourse! Am I missing something?
>>>
>>> Err... yes? fork creates a clone of the current process, exec
>>> changes which file the current process is executing. Any method of
>>> executing an external program, on Unix, ends up calling exec.
>>
>> But for the purposes of END blocks, using fork() before an exec()
>> would allow the END blocks to run anyway:
>
> Sorry, I misunderstood you. Yes, that will work, of course.
>
>> # simplified:
>>
>> END {
>> # clean up stuff here
>> # assuming close-on-exec & equivalents are correctly set
>> }
>>
>> if (! fork()) { # assumin fork() doesn't fail here.
>> exec $whatever;
>> exit;
>
> You need POSIX::_exit here, or the END blocks get run twice (once for
> each process).
This could actually desirable in some cases, such as when you need to
free/clean-up in each child? (Albiet it would probably be done
differently.)
--
szr
------------------------------
Date: Sun, 30 Mar 2008 04:17:21 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: BEGIN, INIT etc...
Message-Id: <87iqz5gdla.fsf@zeekat.nl>
"szr" <szrRE@szromanMO.comVE> writes:
> Ben Morrow wrote:
>> Quoth Joost Diepenmaat <joost@zeekat.nl>:
>>> if (! fork()) { # assumin fork() doesn't fail here.
>>> exec $whatever;
>>> exit;
>>
>> You need POSIX::_exit here, or the END blocks get run twice (once for
>> each process).
>
> This could actually desirable in some cases, such as when you need to
> free/clean-up in each child? (Albiet it would probably be done
> differently.)
Normally, the exec() would succeed, and the exit() would not be called
at all. I tried to ignore all error handling, and that exit() statement
just slipped through.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 30 Mar 2008 00:40:36 +0100
From: jm <jm@nospam.fr>
Subject: Re: Memory issues
Message-Id: <47eed374$0$21145$7a628cd7@news.club-internet.fr>
jm a écrit :
>
> Modifying a little bit again the script, and checking execution with
> ltrace, I observed malloc is called 1871 times when free is just called
> 922 times.
> Isn't it an issue?
>
> and did:
ltrace perl essai.pl 2>&1 | grep 'malloc\|free\|realloc' | perl
observe_malloc_free.pl > memory.log
with observe_malloc_free.pl in mail bottom.
Hereafter, this result of memory leaks:
1 NULL is freed, but thats not a memory leak!
the rest can be read like this:
7 10 Mbytes data are not freed.
1 13 Mbytes data is not freed
8272 4 bytes data are not freed
9843 4080 bytes data are not freed
but I still do not know why...
/tmp$ cat memory.log | sed 's/.*=>//g' | sort | uniq -c
7 10
10 100
7 10000004
22 11
4 112
10 116
1 1192
26 12
1 124
4 128
12 13
1 131716
1 13334528
13 14
3 140
6 15
28 16
9 17
14 18
8 19
19 2
14 20
1 2048
6 21
5 22
3 23
230 24
1 240
6 25
7 256
4 27
1 2712
143 28
4 3
2 30
1 31
125 32
2 33
2 34
1 36
8272 4
3 40
1 4048
1 4064
9843 4080
8 4096
2 4373
1 44
1 45
78 48
1 49156
2 496
72 5
1 50
1 512
65 52
50 56
1 58
6 6
1 628
1 635
13 64
18 7
1 76
45 8
1 80
1 8080
2 84
4 88
74 9
1 98
1 freeing not allocated memory : NULL :
>> --- scipt ---------------------------
>> sub aa($)
>> {
>> my ($d) = @_;
>> $$d =~ s/x(.....)/$1y/g ;
>> $$d =~ s/x(.....)/$1z/g ;
>> $$d =~ s/x(.....)/$1a/g ;
>> $$d =~ s/x(.....)/$1b/g ;
>> $$d =~ s/x(.....)/$1c/g ;
>> return $d;
>> }
>>
>> sub ab($)
>> {
>> my ($d) = @_;
>> $$d =~ s/a(.....)/$1y/g ;
>> $$d =~ s/b(.....)/$1z/g ;
>> $$d =~ s/c(.....)/$1a/g ;
>> $$d =~ s/y(.....)/$1b/g ;
>> $$d =~ s/z(.....)/$1c/g ;
>> return $d;
>> }
>>
>>
>> my $s= 'x' x (1000*1000*10) ;
>> $s .= "\x{1234}" ;
>> my $c = \$s;
>> print length($$c) ."\n" ;
>> my $v = qx( ps v $$ );
>> print "$v\n" ;
>> $c = aa($c);
>> print length($$c) ."\n" ;
>> my $v = qx( ps v $$ );
>> print "$v\n" ;
>> $c = aa($c);
>> $c = aa($c);
>> $c = aa($c);
>> $c = aa($c);
>> $c = aa($c);
>> print length($$c) ."\n" ;
>> my $v = qx( ps v $$ );
>> print "$v\n" ;
>> $c = ab($c);
>> $c = ab($c);
>> $c = ab($c);
>> $c = ab($c);
>> $c = ab($c);
>> print length($$c) ."\n" ;
>> my $v = qx( ps v $$ );
>> print "$v\n" ;
>> $c = ab($c);
>> $c = ab($c);
>> $c = ab($c);
>> $c = ab($c);
>> $c = ab($c);
>> print length($$c) ."\n" ;
>> my $v = qx( ps v $$ );
>> print "$v\n" ;
-- observe...pl --------------------------
my %hash = ();
while (<>)
{
my $line = $_;
#print "jmg:" . $line;
if ( $line =~ m/malloc\(([0-9]*)\).*= *([0-9xa-fNUL]*)/ )
{
my $size = $1;
my $ad = $2;
#print "malloc : $1 : $2 : \n" ;
if ( defined ( $hash{$ad}) )
{
print "redundant malloc : $1 : $2 : \n" ;
}
$hash{$ad} = $size;
}
elsif ( $line =~ m/realloc\(([0-9xa-fNUL]*) *, *([0-9]*)\).*=
*([0-9xa-fNUL]*)/ )
{
my $adp = $1;
my $size = $2;
my $ad = $3;
if ( not defined ( $hash{$adp}) )
{
print "realloc not allocated memory : $adp : \n" ;
}
delete $hash{$adp} ;
#print "malloc : $1 : $2 : \n" ;
if ( defined ( $hash{$ad}) )
{
print "redundant malloc : $size : $ad : \n" ;
}
$hash{$ad} = $size;
}
elsif ( $line =~ m/free\(([0-9xa-fNUL]*)/ )
{
my $ad = $1;
#print "free : $1 : \n" ;
if ( not defined ( $hash{$ad}) )
{
print "freeing not allocated memory : $1 : \n" ;
}
delete $hash{$ad} ;
}
else
{
print "???:" . $line;
}
}
foreach my $key ( keys ( %hash) )
{
print $key . ' => ' . $hash{$key} . "\n" ;
}
------------------------------
Date: Sat, 29 Mar 2008 16:52:45 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: Memory issues
Message-Id: <128b0729-9036-4346-8ca1-0e665a553eb3@y24g2000hsd.googlegroups.com>
On Mar 29, 7:40 pm, jm <j...@nospam.fr> wrote:
> jm a =E9crit :
>
>
>
> > Modifying a little bit again the script, and checking execution with
> > ltrace, I observed malloc is called 1871 times when free is just called
> > 922 times.
> > Isn't it an issue?
>
> > and did:
>
> ltrace perl essai.pl 2>&1 | grep 'malloc\|free\|realloc' | perl
> observe_malloc_free.pl > memory.log
>
> with observe_malloc_free.pl in mail bottom.
>
> Hereafter, this result of memory leaks:
>
> 1 NULL is freed, but thats not a memory leak!
>
> the rest can be read like this:
> 7 10 Mbytes data are not freed.
> 1 13 Mbytes data is not freed
> 8272 4 bytes data are not freed
> 9843 4080 bytes data are not freed
>
> but I still do not know why...
>
I don't know much about the perl garbage collector,
but memory is not freed immediately when the ref
count goes to 0. When I run your program and watch
with top, VM goes to 200 MB and stays there for the
whole run. That seems to be some upper bound where
the garbage collector is running. Memory use does
not continue to go up.
------------------------------
Date: Sun, 30 Mar 2008 01:12:59 +0100
From: jm <jm@nospam.fr>
Subject: Re: Memory issues
Message-Id: <47eedb0b$0$21147$7a628cd7@news.club-internet.fr>
smallpond a écrit :
> On Mar 29, 7:40 pm, jm <j...@nospam.fr> wrote:
>> jm a écrit :
>>
>>
>>
>>> Modifying a little bit again the script, and checking execution with
>>> ltrace, I observed malloc is called 1871 times when free is just called
>>> 922 times.
>>> Isn't it an issue?
>>> and did:
>> ltrace perl essai.pl 2>&1 | grep 'malloc\|free\|realloc' | perl
>> observe_malloc_free.pl > memory.log
>>
>> with observe_malloc_free.pl in mail bottom.
>>
>> Hereafter, this result of memory leaks:
>>
>> 1 NULL is freed, but thats not a memory leak!
>>
>> the rest can be read like this:
>> 7 10 Mbytes data are not freed.
>> 1 13 Mbytes data is not freed
>> 8272 4 bytes data are not freed
>> 9843 4080 bytes data are not freed
>>
>> but I still do not know why...
>>
>
>
> I don't know much about the perl garbage collector,
> but memory is not freed immediately when the ref
> count goes to 0. When I run your program and watch
> with top, VM goes to 200 MB and stays there for the
> whole run. That seems to be some upper bound where
> the garbage collector is running. Memory use does
> not continue to go up.
This is because I have only 500 Mbytes on my computer.
So I made a perl demo program which works within this limit.
Instead of a 10 MBytes string, you can (try to) use a 40 Mbytes string,
or a 100 Mbytes string.
And then, you will see if the garabage collector start at 200 Mbytes,
... or not.
What I only showed with ltrace and observe_malloc_free.pl is that when
the program stops, garbage collector did not collected all garbage.
------------------------------
Date: Sun, 30 Mar 2008 01:13:14 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Memory issues
Message-Id: <87bq4x2hnp.fsf@zeekat.nl>
jm <jm@nospam.fr> writes:
> Modifying a little bit again the script, and checking execution with
> ltrace, I observed malloc is called 1871 times when free is just called
> 922 times.
> Isn't it an issue?
Please keep in mind that perl's memory allocation strategy in general is
optimized for longer running programs, not for one-off scripts (which
makes sense, since one-off scripts don't usually need the performance
gains). This means that for instance subroutines will get memory
allocated on the assumption that they'll be called again, and will take
about as much memory the next time.
This is NOT a memory leak per se, but it does mean that if you have a
subroutine that takes 100Mb to complete, your program will take that
memory and probably not give it back until the program ends. IOW, if you
have a long-running program that only means you need 100Mb for it to
run, it does NOT mean it takes a 100Mb for each call.
In your test case, don't assume that just because the regular expression
replacements don't in theory *need* to use any additional RAM, they
won't. Especially not if you're using UTF-8 encoded strings (which you
are). Perl algorithms tend to exchange RAM for speed in most cases
anyway, and replacing a match with a new string of exactly the same
length in bytes in a unicode string is a pretty uncommon use-case, so
it's likely not optimized.
Anyway, I've not seen a serious memory leak in perl itself in ages, and
I run perl processes that use up to 8 Gb of RAM and run for months
without issues.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 30 Mar 2008 02:16:05 GMT
From: Cosmic Cruizer <XXjbhuntxx@white-star.com>
Subject: NIC Configurations
Message-Id: <Xns9A70C3F77E642ccruizermydejacom@207.115.17.102>
From a Windows box, I need to remotely look at the NICs of about 60 Windows
servers I have administrative accounts on.
I was going to try and use IO::Interface, but I cannot get the module
installed. I cannot find the PPD for IO-Interface-1.04 so I can use ppm.
Does anybody have a Perl solution for getting the NIC configurations on
remote Window servers? Is IO-Interface my best option?
Thanks,
Coz.
------------------------------
Date: 29 Mar 2008 14:39:31 -0400
From: dkcombs@panix.com (David Combs)
Subject: Perl-10: solaris; how to run configure with NO asks, but NOT /usr/local?
Message-Id: <fsm2d3$bc6$1@panix3.panix.com>
Answering all these freaking questions -- you start getting used to
hitting <return> for each one, then OOPS, I didn't mean that (that
G.D. "/usr/local"! -- which I *never* want), and now what do I do?
Well, just keep going, and later on edit the makefile, I suppose.
No, I want to start over, but this time specify up front that
I want everything installed right there under the same directory
I untarred the .gz into.
(I'll get to the executables, etc, via symlinks. And I
assume that if I run the correct executable, it'll know
where to look for its own version's libraries are (that
of course came out of the .tar.gz-file.))
Make any sense?
Basically I want to keep these various perl's totally separate.
Maybe there's a better way. You tell me.
Oh, why no /usr/local. Because the way I partitioned the
disk at the os-install a few years ago, there now not enough
room. And even if there were, I'd still have the separate
perl versions colliding.
Question: how do YOU build a perl? You don't actually sit there
answering each of a gillion (sp?) questions, do you?
Thanks!
David
------------------------------
Date: Sat, 29 Mar 2008 22:25:02 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl-10: solaris; how to run configure with NO asks, but NOT /usr/local?
Message-Id: <u6s2c5-lk6.ln1@osiris.mauzo.dyndns.org>
Quoth dkcombs@panix.com (David Combs):
> Answering all these freaking questions -- you start getting used to
> hitting <return> for each one, then OOPS, I didn't mean that (that
> G.D. "/usr/local"! -- which I *never* want), and now what do I do?
Read INSTALL?
> Well, just keep going, and later on edit the makefile, I suppose.
Configure gives you the option to edit config.sh (which is what you
should be doing if you got something wrong) at the end. Also, at any
question you can answer &-d to take the default answer to all subsequent
questions.
> No, I want to start over, but this time specify up front that
> I want everything installed right there under the same directory
> I untarred the .gz into.
That's a really bad idea. Create another directory parallel to the one
you untarred into; that is, if you untarred into
/home/me/perl/perl-5.8.8 then install in
/home/me/perl/perl-5.8.8-installed or something similar.
> (I'll get to the executables, etc, via symlinks. And I
> assume that if I run the correct executable, it'll know
> where to look for its own version's libraries are (that
> of course came out of the .tar.gz-file.))
The path to the configured install directory is hard-coded, so yes,
assuming you can locate the executable it can handle locating its own
libraries.
> Question: how do YOU build a perl? You don't actually sit there
> answering each of a gillion (sp?) questions, do you?
./Configure -des \
-Uinstallusrbinperl -Dusedevel -Uversiononly \
-Dman1dir=none -Dman3dir=none \
-Dhtml1dir=none -Dhtml3dir=none \
-Dprefix=$inst \
$confargs
where $inst is where I want it installed, and $confargs is anything like
-Duseithreads or -Duse64bitint I want this perl built with. The
-Dusedevel -Uversiononly options are only useful if you are installing a
development version of perl.
Ben
------------------------------
Date: Sat, 29 Mar 2008 13:39:15 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Readline using foreach and while
Message-Id: <fsm9dj027re@news2.newsguy.com>
A. Sinan Unur wrote:
> "szr" <szrRE@szromanMO.comVE> wrote in
> news:fslqmd01gvu@news2.newsguy.com:
>
>> Uri Guttman wrote:
>>>>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
>>>
>>> >> Absolutely not. my %h = map { $_ => 1 } qw/a b c/; is quite a
>>> common >> idiom.
>>>
>>> s> Well, you're still getting that many *sets* which is probably
>>> what I s> should of said, or have been clearer. In that example,
>>> you get 3 set of s> hash pairs resulting from the 3 element
>>> list. The point is you get s> count_of_passed_list amount of
>>> something from the map, in some form or s> another. How exactly
>>> it's returned is determined by the template inside s> the map.
>>>
>>> you are still missing the picture. map can return ANY number of
>>> elements (not sets). it executes its expression/block once for
>>> each input element but that can generate 0-?? elements which are
>>> appended to the return list.
>>
>> I understand, but still, whatever is being generated to the LHS of
>> map, it's done that many times are there are elements in the list
>> on the RHS. Is that fair to say?
>
> If I understand you correctly, yeah, that's fine to say.
>
> On the other hand, you might find the following example instructive:
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use Data::Dumper;
>
> my @result = map { split // } ( '5' x rand(10) ) ;
>
> print Dumper \@result;
>
> __END__
>
> Note that, the RHS is always a single element list. On the other hand,
> the number of elements in the result of map is variable. So, yes, the
> operation inside the block is only carried out once, what you are
> saying is fair in that sense, but the map operation can change the
> length of the list in non-simplistic ways:
Nice example. And yes, this does go with my point. Perhaps I should of
said, the number of elements on the RHS dictates how many passes map
will make. In this case, it's indeed once, where split creates the list
(in fact the map statement is obviously redundant, but I see your
point.)
Thanks.
--
szr
------------------------------
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 V11 Issue 1405
***************************************
