[31780] in Perl-Users-Digest
Perl-Users Digest, Issue: 3043 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jul 25 06:09:39 2010
Date: Sun, 25 Jul 2010 03:09:08 -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 Sun, 25 Jul 2010 Volume: 11 Number: 3043
Today's topics:
Re: Can't locate Unix/Whereis.pm in @INC <jurgenex@hotmail.com>
Cheap jerseys shoes glasses bag necklace jewelry Etc. (ack201)
Re: Confusion about the smart matching operator <nospam-abuse@ilyaz.org>
Re: exist function in perl 5.12.1 <nospam-abuse@ilyaz.org>
Re: exist function in perl 5.12.1 <uri@StemSystems.com>
Re: exist function in perl 5.12.1 <rvtol+usenet@xs4all.nl>
Re: FAQ 5.29 How can I read in an entire file all at on <uri@StemSystems.com>
Re: FAQ 5.29 How can I read in an entire file all at on <nospam-abuse@ilyaz.org>
Re: FAQ 5.29 How can I read in an entire file all at on <hjp-usenet2@hjp.at>
Re: FAQ 8.35 How do I close a process's filehandle with <hjp-usenet2@hjp.at>
Re: Interview question - What is your favourite Perl CP <abigail@abigail.be>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 23 Jul 2010 20:28:53 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Can't locate Unix/Whereis.pm in @INC
Message-Id: <b7nk46pfkolldaq8rphhfaea3vate6a5hs@4ax.com>
kadoudal <kadoudal@gmail.com> wrote:
>I am new to Perl, and I try to run a Perl script which is giving me an
>error on the first line :
>
>use Unix::Whereis; => Can't locate Unix/Whereis.pm in @IN(...
>
> (I believe a module is missing ...
That seems to be an accurate observation.
>I am using the pre-installed Perl
>on Mac OSX 10.6 (Snow)
>
>should I need to add anything to my install ?
Apparently yes.
However, I can't find said module anywhere, either. It is not on CPAN
(http://search.cpan.org/), so most likely it is a private module and you
will have to ask at the place where you got your program.
> (whereis command is
>running welll in the console)
The one has nothing to do with the other.
>or just to add any path somewhere ?
Possible. Search for Whereis.pm. Maybe you are lucky and you got it
somewhere already.
jue
------------------------------
Date: Sun, 25 Jul 2010 03:22:43 +0000
From: nameack_at_yahoo_dot_com@foo.com (ack201)
Subject: Cheap jerseys shoes glasses bag necklace jewelry Etc.
Message-Id: <6c9a8$4c4bae03$cf3aab60$21166@news.flashnewsgroups.com>
Our Factory product collection is produced over 1000 types including
Fashion jeans， watch， hat，
shoes， jersey shoes， glasses， bag，
necklace，belt， jewelry Etc.
http://picasaweb.google.de/189trade Absolutely the most affordable price
absolute guarantee of
quality assured. http://picasaweb.google.ca/SL6688SL And professional
shopping service.
http://picasaweb.google.fr/dttrade1
ack201@hotmail.com
nameack@yahoo.com
--
+--------------------------[ SERVER SIGNATURE ]-----+
| Article posted vie Web Developer's USENET Archive |
| http://www.1-script.com/forums/ |
| Web and RSS gateway to your favorite newsgroup - |
| comp.lang.perl.misc |
+---------------------------------------------------+
------------------------------
Date: Sat, 24 Jul 2010 06:38:29 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Confusion about the smart matching operator
Message-Id: <slrni4l2j5.97q.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-07-23, jl_post@hotmail.com <jl_post@hotmail.com> wrote:
> I find this a bit counter-intuitive.
There is nothing "a bit counter-intuitive" about the smart matching
operation. It is just *absolutely useless*, since there is no
humanly-possible way to predict what it would do.
The only way to handle the situation is to ignore this operator
completely, and black-list as unmaintainable any code which uses it.
Hope this helps,
Ilya
------------------------------
Date: Sat, 24 Jul 2010 06:33:57 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: exist function in perl 5.12.1
Message-Id: <slrni4l2al.97q.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-07-23, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "D" == Dilbert <dilbert1999@gmail.com> writes:
>
> D> Let's hope that the surprising autovivification will be fixed in Perl
> D> 5.14
> let's hope not!
lets hope yes
> exists was just a function that provided no information
> to the hash expression it was checking.
... which in 99.9999% of cases is not what the intent was.
> the autoviv happens in the hash
> lookup no matter what the outer code is doing. changing that could break
> existing code
True. So one may hook it on `use 5.14' or whatever.
Ilya
------------------------------
Date: Sat, 24 Jul 2010 02:53:42 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: exist function in perl 5.12.1
Message-Id: <878w51qsjt.fsf@quad.sysarch.com>
>>>>> "IZ" == Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
IZ> On 2010-07-23, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>>> "D" == Dilbert <dilbert1999@gmail.com> writes:
>>
D> Let's hope that the surprising autovivification will be fixed in Perl
D> 5.14
>> let's hope not!
IZ> lets hope yes
>> exists was just a function that provided no information
>> to the hash expression it was checking.
IZ> ... which in 99.9999% of cases is not what the intent was.
and writing a deep exists is such an easy task anyhow. doing direct deep
exists is usually poor code as well. see my autovivication tutorial for
more and the code for a deep exists.
http://sysarch.com/Perl/autoviv.txt
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Sat, 24 Jul 2010 14:09:16 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: exist function in perl 5.12.1
Message-Id: <4c4ad7ed$0$22943$e4fe514c@news.xs4all.nl>
Dilbert wrote:
>> On Jul 23, 10:40 am, Dilbert <dilbert1...@gmail.com> wrote:
> http://perldoc.perl.org/5.8.8/functions/exists.html
>
>>> This surprising autovivification in what does not at first -- or even
>>> second -- glance appear to be an lvalue context may be fixed in
>>> a future release.
>
> Let's hope that the surprising autovivification will be fixed in Perl
> 5.14
It is not surprising, and it should not get changed.
$ perl -MData::Dumper -wle'
my $x;
print Dumper( $x ) if $x->{a}{b}{c}{d} or $x;
'
$VAR1 = {
'a' => {
'b' => {
'c' => {}
}
}
};
Insecurity about intermediate levels, just means that your model is wrong.
You can of course write your own deep_exists() to do what you think that
you need, but you really need to go back to the drawing board.
--
Ruud
------------------------------
Date: Fri, 23 Jul 2010 18:15:05 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: FAQ 5.29 How can I read in an entire file all at once?
Message-Id: <87y6d1u9p2.fsf@quad.sysarch.com>
>>>>> "TW" == Tim Watts <tw@dionic.net> writes:
TW> Uri Guttman <uri@StemSystems.com>
TW> wibbled on Sunday 04 July 2010 06:15
>> i disagree with that last point. mmap always needs virtual ram allocated
>> for the entire file to be mapped. it only saves ram if you map part of
>> the file into a smaller virtual window. the win of mmap is that it won't
>> do the i/o until you touch a section. so if you want random access to
>> sections of a file, mmap is a big win. if you are going to just process
>> the whole file, there isn't any real win over File::Slurp
TW> I think it is worth some clarification - at least under linux:
TW> mmap requires virtual address space, not RAM per se, for the
TW> initial mmap.
TW> Obviously as soon as you try to read any part of the file, those
TW> blocks must be paged in to actual RAM pages.
TW> However, if you then ignore those pages and have not modified
TW> them, the LRU recovery sweeper can just drop those pages.
but a slurped file in virtual ram behaves the same way. it may be
swapped in when you read in the file and process it but as soon as that
is done, and you free the scalar in perl, perl can reuse the space. the
virtual ram can't be given back to the os but the real ram is reused.
TW> Compare to if you slurp the file into some virtual RAM that's been malloc'd:
TW> The RAM pages are all dirty (because you copied data into them) -
TW> so if the system needs to reduce the working page set, it will
TW> have to page those out to swap rather than just dropping them - it
TW> no longer has the knowledge that they are in practise backed by
TW> the original file.
that is true. the readonly aspect of a mmap slurp is a win. but given
the small sizes of most files slurped it isn't that large a win. today
we have 4k or larger page sizes and many files are smaller than
that. ram and vram are cheap as hell so fighting for each byte is a long
lost art that needs to die. :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 23 Jul 2010 23:20:59 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: FAQ 5.29 How can I read in an entire file all at once?
Message-Id: <slrni4k8ur.8c1.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-07-23, Uri Guttman <uri@StemSystems.com> wrote:
> mmap still needs space in the program. it may be allocated with malloc
> or even builtin these days (haven't used it directly in decades! :). now
> real ram could be saved but that is true for all virtual memory use. if
> you seek into the mmap space and only read/write parts, then the other
> sections won't be touched. so the issue comes down to random access vs
> processing a whole file. most uses of slurp are for processing a whole
> file so i would lean in that direction. someone sophisticated enough to
> use mmap directly for random access should know the resource usage issues.
I do not see it mentioned in this discussion that (a good
implemenation of) mmap() also semi-unmaps-when-needed. So as far as
you have enough *virtual* memory, mmap() behaves as a "smartish"
intermediate ground between reading-by-line and slurping. And it
"almost scales"; the limit is the virtual memory, so on 64bit systems
it might even "absolutely scale".
Of course, this can severely limit the amount of free physical memory
on the computer, so may harden the life of other programs, AND
decrease disk caching. However, if YOUR program is the only one on
CPU, and THIS disk access is the only one in question, mmap() has a
chance to be a clear win...
Yours,
Ilya
------------------------------
Date: Sun, 25 Jul 2010 11:08:39 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: FAQ 5.29 How can I read in an entire file all at once?
Message-Id: <slrni4nvoo.v07.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-23 22:15, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "TW" == Tim Watts <tw@dionic.net> writes:
>
> TW> Uri Guttman <uri@StemSystems.com>
> TW> wibbled on Sunday 04 July 2010 06:15
>
> >> i disagree with that last point. mmap always needs virtual ram allocated
> >> for the entire file to be mapped. it only saves ram if you map part of
> >> the file into a smaller virtual window. the win of mmap is that it won't
> >> do the i/o until you touch a section. so if you want random access to
> >> sections of a file, mmap is a big win. if you are going to just process
> >> the whole file, there isn't any real win over File::Slurp
>
> TW> I think it is worth some clarification - at least under linux:
> TW> mmap requires virtual address space, not RAM per se, for the
> TW> initial mmap.
>
> TW> Obviously as soon as you try to read any part of the file, those
> TW> blocks must be paged in to actual RAM pages.
>
> TW> However, if you then ignore those pages and have not modified
> TW> them, the LRU recovery sweeper can just drop those pages.
>
> but a slurped file in virtual ram behaves the same way. it may be
> swapped in when you read in the file and process it but as soon as that
> is done, and you free the scalar in perl, perl can reuse the space.
Well, *if* you free it. The nice thing about mmap is that RAM can be
reused even if you don't free it.
> the virtual ram can't be given back to the os
That depends on the malloc implementation. GNU malloc uses heap based
allocation only for small chunks (less than 128 kB by default, I think),
but mmap-based allocation for larger chunks. So for a scalar larger than
128 kB, the space can and will be given back to the OS.
> but the real ram is reused.
> TW> Compare to if you slurp the file into some virtual RAM that's been malloc'd:
>
> TW> The RAM pages are all dirty (because you copied data into them) -
> TW> so if the system needs to reduce the working page set, it will
> TW> have to page those out to swap rather than just dropping them - it
> TW> no longer has the knowledge that they are in practise backed by
> TW> the original file.
>
> that is true. the readonly aspect of a mmap slurp is a win. but given
> the small sizes of most files slurped it isn't that large a win.
Yes. Mmap is only a win for large files. And I suspect "large" means
really large - somewhere on the same order as available RAM.
> today we have 4k or larger page sizes and many files are smaller than
> that. ram and vram are cheap as hell so fighting for each byte is a
> long lost art that needs to die. :)
I wish Perl would fight for each byte at the low level. The overhead for
each scalar, array element or hash element is enormous, and these really
add up if you have enough of them.
hp
------------------------------
Date: Sun, 25 Jul 2010 10:46:43 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: FAQ 8.35 How do I close a process's filehandle without waiting for it to complete?
Message-Id: <slrni4nufk.v07.hjp-usenet2@hrunkner.hjp.at>
On 2010-07-25 04:00, PerlFAQ Server <brian@theperlreview.com> wrote:
> 8.35: How do I close a process's filehandle without waiting for it to complete?
>
> Assuming your system supports such things, just send an appropriate
> signal to the process (see "kill" in perlfunc). It's common to first
> send a TERM signal, wait a little bit, and then send a KILL signal to
> finish it off.
To me "closing a file handle" and "killing a process" are two completely
different concepts. If somebody asks this question and it turns out that
killing the process is what they need to do then I smell an XY problem.
hp
------------------------------
Date: 24 Jul 2010 15:27:03 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Interview question - What is your favourite Perl CPAN Module?
Message-Id: <1523371480301677796.309756abigail-abigail.be@news.xs4all.nl>
Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> wrote:
>
> One obvious question, which I've used in the past, would be "how often
> do you use CPAN?" If it's not very often, I can speculate that the
> person is writing a lot of his own code instead of using what's
> already
> out there.
>
Or the person is mostly writing business logic specific
to their work. At $WORK I hardly use CPAN modules.
Abigail
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3043
***************************************
