[32982] in Perl-Users-Digest
Perl-Users Digest, Issue: 4258 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 31 21:09:19 2014
Date: Thu, 31 Jul 2014 18:09:06 -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 Thu, 31 Jul 2014 Volume: 11 Number: 4258
Today's topics:
Re: Determining the last key when iterating through a h <uri@stemsystems.com>
Re: Not having good luck with cpan (Tim McDaniel)
perl process memory <gravitalsun@hotmail.foo>
Re: perl process memory <gamo@telecable.es>
Re: perl process memory <gravitalsun@hotmail.foo>
Re: perl process memory <rweikusat@mobileactivedefense.com>
Re: perl process memory <derykus@gmail.com>
Re: perl process memory <gravitalsun@hotmail.foo>
Re: Regex to select between first and third occurence o <bauhaus@futureapps.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 31 Jul 2014 00:57:39 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Determining the last key when iterating through a hash
Message-Id: <87silicegs.fsf@stemsystems.com>
>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
TM> In article <871tt6e2gi.fsf@stemsystems.com>,
TM> Uri Guttman <uri@stemsystems.com> wrote:
>>
>> but $last is undef and will cause the loop to iterate one time.
TM> What are you going on about? The loop works perfectly fine if
TM> @regular is empty.
@regular isn't empty for the pop call.
TM> #! /usr/bin/perl
TM> use strict;
TM> use warnings;
TM> my %signals = (A => 3);
TM> my @regular = sort keys %signals;
TM> my $last = pop @regular;
TM> if (@regular == 0) {
TM> print "regular is empty ...";
TM> }
TM> if (! defined $last) {
TM> print "but last is not undef\n";
TM> }
TM> foreach my $item (@regular, $last) {
TM> print "item is [$item]\n";
of course that works fine as @regular is empty then. my point was if
@regular was empty before the pop, then $last would have undef and that
would cause a loop iteration.
TM> If you mean that %signals is empty, so @regular STARTS OUT empty, I
TM> will write for the third time that the coder would need to check first
TM> whether %signals is empty and do something appropriate in that case.
that was my point but i didn't see your earlier comments. i was just
looking at your code and seeing it would iterate if @regular was empty.
>> better to do:
>>
>> $last = $regular[-1] ;
>> foreach my $item( @regular ) {
>>
>> then you will only loop if you have elements and you can still test for
>> last.
TM> That *is* a better scheme, not needing a separate "if" to check for
TM> empty %signals, though I dislike deliberate undefs.
uri
------------------------------
Date: Thu, 31 Jul 2014 00:41:46 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Not having good luck with cpan
Message-Id: <lrc3ca$8va$1@reader1.panix.com>
In article <MPG.2e333ec4cabee0999897d5@news.eternal-september.org>,
John Black <johnblack@nospam.com> wrote:
>I've been trying to install GD:Simple for a while and ran into several issues which I tried
>hacking. I kept getting farther but still could not complete. I won't go into those yet
>because it was suggested to me to first try upgrading my cpan to the latest version with:
>
>cpan> install Bundle::CPAN
>
>This won't even work for me. Well it may finish eventually (not sure) but its been running
>for hours slowed down by tons of these kinds of messages.
>
>0 [main] perl 6116 child_info_fork::abort: address space needed by 'Dumper.dll' (0x450000) is
>already occupied
>Can't fork, trying again in 5 seconds at t/31sessions.t line 526.
>
>Its always Dumper.dll at that same address. Has anyone seen that or know of a solution?
I did a Google search for
"address space needed by" cygwin
It's a frequent Cygwin situation. Try updating your Cygwin install to
the latest. If that doesn't fix it, then try following the links in
http://stackoverflow.com/questions/11107155/how-to-fix-address-space-is-already-occupied-error-on-fetch-commit
specifically the two FAQ sections. If that doesn't work, you can try
rebaseall -- the first FAQ link mentions the rebase package's README,
and if you can't read that, there's a link to a Rebaseall Wiki entry.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 30 Jul 2014 20:55:14 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: perl process memory
Message-Id: <lrbbi2$1toc$1@news.ntua.gr>
any other way than "grep VmSize /proc/830/status" ?
------------------------------
Date: Wed, 30 Jul 2014 20:53:31 +0200
From: gamo <gamo@telecable.es>
Subject: Re: perl process memory
Message-Id: <lrbevv$tjr$1@speranza.aioe.org>
El 30/07/14 a las #4, George Mpouras escribió:
> any other way than "grep VmSize /proc/830/status" ?
In my linux
ps u | grep programname | cut -d' ' -f5
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Wed, 30 Jul 2014 22:19:38 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: perl process memory
Message-Id: <lrbgga$29am$1@news.ntua.gr>
On 30/7/2014 9:53 μμ, gamo wrote:
> grep VmSize /proc/830/status"
I want to know how much mem the process consumes. mayme the following is
closer to the truth
`ps --no-headers -o rss -p $$`
I do not know if exists a super secret special variable or something
having this info
------------------------------
Date: Wed, 30 Jul 2014 20:53:18 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl process memory
Message-Id: <87mwbq8vyp.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 30/7/2014 9:53 ¦Ì¦Ì, gamo wrote:
>> grep VmSize /proc/830/status"
>
> I want to know how much mem the process consumes. mayme the following
> is closer to the truth
>
> `ps --no-headers -o rss -p $$`
In general, you can't know that as real memory is assigned to areas of
the virtual address space of the process on demand (and possibly removed
later on).
------------------------------
Date: Wed, 30 Jul 2014 22:02:42 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: perl process memory
Message-Id: <lrcim1$942$1@speranza.aioe.org>
On 7/30/2014 10:55 AM, George Mpouras wrote:
> any other way than "grep VmSize /proc/830/status" ?
I haven't tried it but Tim Bunce's Devel::SizeMe may be of interest
since it tries to track where memory is held - rather than allocated -
IIUC.
http://blog.timbunce.org/2012/10/05/introducing-develsizeme-visualizing-perl-memory-use/
--
Charles DeRykus
------------------------------
Date: Thu, 31 Jul 2014 12:37:37 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: perl process memory
Message-Id: <lrd2p6$3qa$1@news.ntua.gr>
On 31/7/2014 8:02 πμ, Charles DeRykus wrote:
> On 7/30/2014 10:55 AM, George Mpouras wrote:
>> any other way than "grep VmSize /proc/830/status" ?
>
> I haven't tried it but Tim Bunce's Devel::SizeMe may be of interest
> since it tries to track where memory is held - rather than allocated -
> IIUC.
>
> http://blog.timbunce.org/2012/10/05/introducing-develsizeme-visualizing-perl-memory-use/
>
>
not what I need (traking the memory of every data structure) but install
it and play a litle at my centos 7 vm. Impressive work !
------------------------------
Date: Wed, 30 Jul 2014 19:01:56 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: Regex to select between first and third occurence of comma
Message-Id: <lrb8e4$9v4$1@dont-email.me>
On 28.07.14 13:31, Henry Law wrote:
> Here our discussion founders on whether or not the code being written is
> for a specific data set whose format is known in detail and consistent.
Do these exist? Consistently comma separated values I mean?
(For illustration: working with sheets turned CSV from
various "settings", including varying locales, is not fun,
really. A Googlean approach seemed to work best then, i.e.
ignore most kinds of optimism regarding structure.)
------------------------------
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 4258
***************************************
