[30192] in Perl-Users-Digest
Perl-Users Digest, Issue: 1435 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 10 06:13:56 2008
Date: Thu, 10 Apr 2008 03:12:49 -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, 10 Apr 2008 Volume: 11 Number: 1435
Today's topics:
? about using multi-level menu system using dispatch me <mmccaws@comcast.net>
Re: ? about using multi-level menu system using dispatc <RedGrittyBrick@SpamWeary.foo>
Re: every combination of Y/N in 5 positions <hjp-usenet2@hjp.at>
Re: Perl Regex substitution: replace nth occurrance <someone@example.com>
Re: problem using system() <glex_no-spam@qwest-spam-no.invalid>
Re: SOAP <kevino_2@yahoo.com>
Re: SOAP <RedGrittyBrick@SpamWeary.foo>
Re: SOAP <kevino_2@yahoo.com>
Re: SOAP <RedGrittyBrick@SpamWeary.foo>
Re: SOAP xhoster@gmail.com
Re: Trouble with @ARGV <rkb@i.frys.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 9 Apr 2008 09:25:58 -0700 (PDT)
From: mmccaws2 <mmccaws@comcast.net>
Subject: ? about using multi-level menu system using dispatch method
Message-Id: <850fba42-ab25-43cb-96f7-1415a7bfa79a@u3g2000hsc.googlegroups.com>
It's a general question on how do I make sure that I'm not eating up
memory unnecessarily. I have a script that is used as a user
interface to:
monitoring the status of application's several scripts,
stopping, starting, and creating projects within the application
A project is defined as the set of actions required to be implemented
by the collection of scripts. All the settings are stored in a DB by
this script, then the script can start and stop the application's set
of scripts.
The question is how do I make sure that I'm not unnecessarily eating
memory (is this what you may call creating zombies?). How do I go
about monitoring those resources. Is there a good link or book
addressing this?
Thanks
Mike
------------------------------
Date: Wed, 09 Apr 2008 17:45:06 +0100
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: ? about using multi-level menu system using dispatch method
Message-Id: <47fcf295$0$10638$fa0fcedb@news.zen.co.uk>
mmccaws2 wrote:
> It's a general question
This is a general answer.
> on how do I make sure that I'm not eating up
> memory unnecessarily.
My first step would be to find out if, in fact, memory is being eaten up
uneccessarily. I'd monitor the program over an extended period of time
using the tools provided by the operating system that show the program's
memory usage.
> I have a script that is used as a user
> interface to:
> monitoring the status of application's several scripts,
> stopping, starting, and creating projects within the application
>
> A project is defined as the set of actions required to be implemented
> by the collection of scripts. All the settings are stored in a DB by
> this script, then the script can start and stop the application's set
> of scripts.
> The question is how do I make sure that I'm not unnecessarily eating
> memory (is this what you may call creating zombies?).
Processes on a Unix-like operating system which have finished their work
wait to tell their parents their exit code - they wait for their parent
to "reap" them. If the parents have lost interest in them, the parents
never "reap" the children and the children, have finished (died) but are
unable to part the mortal plane - they are zombies. This is usually the
result of a programming bug (usually in your program rather than the
language/compiler etc).
AFAIK zombies usually consume minimal resources in terms of memory, etc,
but occupy slots in the process table such that it if they multiply in
an unlimited way, the OS may eventually be unable to start any new
process due to lack of resources (like process table slots). It is a
long time since I first encountered this so the details may differ in
current OSs.
If you get the parents to exit/restart (in the worst case use `kill`)
the zombies will be inherited by the "init" process which will reap them
and make them go away.
> How do I go about monitoring those resources.
How I'd do it depends on
* which resources
* which operating system
--
RGB
------------------------------
Date: Wed, 9 Apr 2008 19:14:55 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: every combination of Y/N in 5 positions
Message-Id: <slrnfvpucg.1nn.hjp-usenet2@hrunkner.hjp.at>
On 2008-04-02 03:34, Robbie Hatley <see.my.signature@for.my.email.address> wrote:
> Gunnar Hjalmarsson wrote:
>> ... it's easy to write obfuscated code using Perl...
>> perl -le"do{$_=sprintf'%05b',$_;y/01/NY/;print}for(0..0b11111)"
>
> Huh. That doesn't look "obfuscated" to me at all.
Nor to me. Except for the lack of whitespace and possibly the
reassignement to $_, that's pretty readable.
> (As a newbie Perl programmer, I don't know whether the fact that the
> above one-liner doesn't seem "obfuscated" to me should make me happy
> or terrified. Perhaps a little of both.)
>
> Maybe you're using the wrong language. Try C for obfuscation:
[...]
Somebody once said that there is no Obfuscated Perl Code Contest because
it would be pointless. He was wrong on both counts: Firstly, writing
"obfus" ist a favorite pastime of some perl programmers, and there are
contests (although AFAIK there is no global, annual contest like the
OCCC), and secondly, not all (or even most) Perl code is obfuscated. It
is perfectly possible to write sane, readable Perl code. But it is also
possible to write code which is even more obfuscated in Perl than in C
(for once, Perl code can modify itself, which (portable) C can't).
For a beautiful (and rather famous) example, of a Perl obfu, see
http://www.perlmonks.org/index.pl?node=camel code
hp
------------------------------
Date: Wed, 09 Apr 2008 18:08:43 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Perl Regex substitution: replace nth occurrance
Message-Id: <LC7Lj.19012$9X3.3215@edtnps82>
Yogi wrote:
> Hi Guys,
> I have a variable say:
> $x = "this is test program with test inputs";
>
> My requirement is to replace nth occurrance of "test" with something
> else. how to achieve the same using perl regex. if i do something
> like:
> $x =~ s/test/java/g;
>
> This is going to replace all occurrance of test with "java" but my
> requirement is to replace say 2nd occurrance only. Any help?
$ perl -le'
my $test = q[ 1 test 2 test 3 test 4 test 5 test 6 test 7 test ];
print $test;
my $count;
my $to_java = 4;
while ( $test =~ /test/g ) {
if ( $to_java == ++$count ) {
substr $test, $-[0], $+[0] - $-[0], q[java];
}
}
print $test;
'
1 test 2 test 3 test 4 test 5 test 6 test 7 test
1 test 2 test 3 test 4 java 5 test 6 test 7 test
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order. -- Larry Wall
------------------------------
Date: Wed, 09 Apr 2008 10:21:14 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: problem using system()
Message-Id: <47fcdeea$0$87070$815e3792@news.qwest.net>
mike wrote:
> Hi,
>
> I changed it to ( taking all pointers into account):
>
>
> my @args = ($User_Preferences{asadminexecutable}, 'deploy', "--user=
> $User_Preferences{user}","--passwordfile=
> $User_Preferences{passwordfile}","--host=$User_Preferences{host}","--
> port=$User_Preferences{port}","$User_Preferences{pathdeployunit}");
Could also make that easier to read:
my @args = (
$User_Preferences{asadminexecutable},
'deploy',
"--user=$User_Preferences{user}",
"--passwordfile=$User_Preferences{passwordfile}",
"--host=$User_Preferences{host}",
"--port=$User_Preferences{port}",
"$User_Preferences{pathdeployunit}",
);
------------------------------
Date: Wed, 9 Apr 2008 08:18:42 -0700 (PDT)
From: KevinO <kevino_2@yahoo.com>
Subject: Re: SOAP
Message-Id: <e6ddf8ba-5259-4b2d-9ea4-ee4b6867cbb2@8g2000hse.googlegroups.com>
On Apr 9, 11:07 am, nolo contendere <simon.c...@fmr.com> wrote:
> On Apr 9, 11:03 am, KevinO <kevin...@yahoo.com> wrote:
>
>
>
> > On Apr 9, 9:40 am, Matija Papec <n...@yahoo.com> wrote:
>
> > > KevinO wrote:
> > > > Hi
>
> > > > I "inherited" a program which contains this line:
> > > > $a = $soap->call( $retrieveXmlList => @params )->result ;
>
> > > > I added:
> > > > print "$a\n" ;
>
> > > > Which produced:
> > > > HASH(0x50c5d4)
>
> > > > How do I proceed from here to see and parse the XML tree/data?
>
> > > Most probably you don't need to parse anything, as $a already contain
> > > final result from soap call.
>
> > > use Data::Dumper;
> > > print Dumper $a
>
> > Matija
>
> > Thanks for the quick response.
> > However, it seems that the Dumper returns only the last item in the
> > list.
>
> Why do you jump to this conclusion rather than guess that the thing
> that Dumper is trying to dump only has the last item?
I don't know Perl well enough and Dumper in particular. That leaves
me with only one option - make assumptions and respectfully ask for
help.
KO
------------------------------
Date: Wed, 09 Apr 2008 16:27:29 +0100
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: SOAP
Message-Id: <47fce064$0$32041$da0feed9@news.zen.co.uk>
KevinO wrote:
> On Apr 9, 11:07 am, nolo contendere <simon.c...@fmr.com> wrote:
>> On Apr 9, 11:03 am, KevinO <kevin...@yahoo.com> wrote:
>>
>>
>>
>>> On Apr 9, 9:40 am, Matija Papec <n...@yahoo.com> wrote:
>>>> KevinO wrote:
>>>>> Hi
>>>>> I "inherited" a program which contains this line:
>>>>> $a = $soap->call( $retrieveXmlList => @params )->result ;
>>>>> I added:
>>>>> print "$a\n" ;
>>>>> Which produced:
>>>>> HASH(0x50c5d4)
>>>>> How do I proceed from here to see and parse the XML tree/data?
>>>> Most probably you don't need to parse anything, as $a already contain
>>>> final result from soap call.
>>>> use Data::Dumper;
>>>> print Dumper $a
>>> Matija
>>> Thanks for the quick response.
>>> However, it seems that the Dumper returns only the last item in the
>>> list.
>> Why do you jump to this conclusion rather than guess that the thing
>> that Dumper is trying to dump only has the last item?
>
> I don't know Perl well enough and Dumper in particular. That leaves
> me with only one option - make assumptions and respectfully ask for
> help.
>
Your problem may be not with Dumper but with the way you are using
SOAP::Lite - try this:
my $response = $soap->call($retrieveXmlList => @params);
my @results = $response->result; # 1st returned value
print "\n1.\n", Dumper(@results);
@results = $response->paramsout; # 2nd ... returned values
print "\n2.\n", Dumper(@results)
@results = $reponse->paramsall; # 1st, 2nd ... returned values
print "\n3.\n", Dumper(@results);
--
RGB
------------------------------
Date: Wed, 9 Apr 2008 09:30:44 -0700 (PDT)
From: KevinO <kevino_2@yahoo.com>
Subject: Re: SOAP
Message-Id: <74c9d371-b414-4360-8e2c-f42a4a2262f9@e67g2000hsa.googlegroups.com>
On Apr 9, 11:27 am, RedGrittyBrick <RedGrittyBr...@SpamWeary.foo>
wrote:
> KevinO wrote:
> > On Apr 9, 11:07 am, nolo contendere <simon.c...@fmr.com> wrote:
> >> On Apr 9, 11:03 am, KevinO <kevin...@yahoo.com> wrote:
>
> >>> On Apr 9, 9:40 am, Matija Papec <n...@yahoo.com> wrote:
> >>>> KevinO wrote:
> >>>>> Hi
> >>>>> I "inherited" a program which contains this line:
> >>>>> $a = $soap->call( $retrieveXmlList => @params )->result ;
> >>>>> I added:
> >>>>> print "$a\n" ;
> >>>>> Which produced:
> >>>>> HASH(0x50c5d4)
> >>>>> How do I proceed from here to see and parse the XML tree/data?
> >>>> Most probably you don't need to parse anything, as $a already contain
> >>>> final result from soap call.
> >>>> use Data::Dumper;
> >>>> print Dumper $a
> >>> Matija
> >>> Thanks for the quick response.
> >>> However, it seems that the Dumper returns only the last item in the
> >>> list.
> >> Why do you jump to this conclusion rather than guess that the thing
> >> that Dumper is trying to dump only has the last item?
>
> > I don't know Perl well enough and Dumper in particular. That leaves
> > me with only one option - make assumptions and respectfully ask for
> > help.
>
> Your problem may be not with Dumper but with the way you are using
> SOAP::Lite - try this:
>
> my $response = $soap->call($retrieveXmlList => @params);
>
> my @results = $response->result; # 1st returned value
> print "\n1.\n", Dumper(@results);
>
> @results = $response->paramsout; # 2nd ... returned values
> print "\n2.\n", Dumper(@results)
>
> @results = $reponse->paramsall; # 1st, 2nd ... returned values
> print "\n3.\n", Dumper(@results);
>
> --
> RGB
RGB
First - THANKS.
(1.) returns the last item in the list.
(2.) returns nothing, no error message.
(3.) returns nothing + this error message: "Can't call method
"paramsall" on an undefined value at retrieveXmlList.pl line 38."
KO
------------------------------
Date: Wed, 09 Apr 2008 17:50:54 +0100
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: SOAP
Message-Id: <47fcf3f1$0$10638$fa0fcedb@news.zen.co.uk>
KevinO wrote:
> On Apr 9, 11:27 am, RedGrittyBrick <RedGrittyBr...@SpamWeary.foo>
> wrote:
>> KevinO wrote:
>>> On Apr 9, 11:07 am, nolo contendere <simon.c...@fmr.com> wrote:
>>>> On Apr 9, 11:03 am, KevinO <kevin...@yahoo.com> wrote:
>>>>> On Apr 9, 9:40 am, Matija Papec <n...@yahoo.com> wrote:
>>>>>> KevinO wrote:
>>>>>>> Hi
>>>>>>> I "inherited" a program which contains this line:
>>>>>>> $a = $soap->call( $retrieveXmlList => @params )->result ;
>>>>>>> I added:
>>>>>>> print "$a\n" ;
>>>>>>> Which produced:
>>>>>>> HASH(0x50c5d4)
>>>>>>> How do I proceed from here to see and parse the XML tree/data?
>>>>>> Most probably you don't need to parse anything, as $a already contain
>>>>>> final result from soap call.
>>>>>> use Data::Dumper;
>>>>>> print Dumper $a
>>>>> Matija
>>>>> Thanks for the quick response.
>>>>> However, it seems that the Dumper returns only the last item in the
>>>>> list.
>>>> Why do you jump to this conclusion rather than guess that the thing
>>>> that Dumper is trying to dump only has the last item?
>>> I don't know Perl well enough and Dumper in particular. That leaves
>>> me with only one option - make assumptions and respectfully ask for
>>> help.
>> Your problem may be not with Dumper but with the way you are using
>> SOAP::Lite - try this:
>>
>> my $response = $soap->call($retrieveXmlList => @params);
>>
>> my @results = $response->result; # 1st returned value
>> print "\n1.\n", Dumper(@results);
>>
>> @results = $response->paramsout; # 2nd ... returned values
>> print "\n2.\n", Dumper(@results)
>>
>> @results = $reponse->paramsall; # 1st, 2nd ... returned values
>> print "\n3.\n", Dumper(@results);
>>
>
> First - THANKS.
>
> (1.) returns the last item in the list.
> (2.) returns nothing, no error message.
> (3.) returns nothing + this error message: "Can't call method
> "paramsall" on an undefined value at retrieveXmlList.pl line 38."
>
Hmm, I think there is something wrong with your server, not with your
client.
Change the client so that where you define your "$soap" you make a
change like
from
use SOAP::Lite +autodispatch =>
uri => 'http://www.jmac.org/ISBN',
proxy => 'http://www.jmac.org/projects/bookdb/isbn/lookup.pl';
to
use SOAP::Lite +autodispatch =>
uri => 'http://www.jmac.org/ISBN',
outputxml => 1,
proxy => 'http://www.jmac.org/projects/bookdb/isbn/lookup.pl';
In other words, use the outputxml option.
Post the XML results here (sanitized if need be) - it will show exactly
what your server is sending.
--
RGB
------------------------------
Date: 09 Apr 2008 16:57:04 GMT
From: xhoster@gmail.com
Subject: Re: SOAP
Message-Id: <20080409125705.952$YA@newsreader.com>
KevinO <kevino_2@yahoo.com> wrote:
> >
> > Your problem may be not with Dumper but with the way you are using
> > SOAP::Lite - try this:
> >
> > my $response = $soap->call($retrieveXmlList => @params);
> >
> > my @results = $response->result; # 1st returned value
> > print "\n1.\n", Dumper(@results);
> >
> > @results = $response->paramsout; # 2nd ... returned values
> > print "\n2.\n", Dumper(@results)
> >
> > @results = $reponse->paramsall; # 1st, 2nd ... returned values
> > print "\n3.\n", Dumper(@results);
> >
> > --
> > RGB
>
> RGB
>
> First - THANKS.
>
> (1.) returns the last item in the list.
How do you know it is the last item, rather than the *only* item,
in the list? The first step to debugging is the verify that there
is a bug. Maybe the error is in your expectations. Can you come up with
any example code which proves that there is more than one item to be found?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Wed, 9 Apr 2008 08:44:46 -0700 (PDT)
From: Ron Bergin <rkb@i.frys.com>
Subject: Re: Trouble with @ARGV
Message-Id: <95cf3247-e90c-4bd0-87c1-85050c1c9c1d@c19g2000prf.googlegroups.com>
On Apr 9, 4:13 am, ff0000 <ff0000...@gmail.com> wrote:
> Hi,
>
> > Perhaps you could look at @ARGV as a string, and set your own parsing rules.
>
> > my $aline = "@ARGV";
> > # ..
> > # remove leading "--", etc.
>
> > my %opt = map { split /=/ } split /,/, $aline;
>
> > use Data::Dumper;
> > print Dumper \%opt;
>
> I can't split in such way, because i invoke this:
>
> $ perl_script.pl --option=value_1,value_2="a simple, string"
>
> but to perl arrive this @ARGV:
>
> --option=value_1,value_2=a simple, string
>
> and your dump isn't pretty good:
>
> $ ./test.pl --option=value_1,value_2="a simple, string"
>
> $VAR1 = {
> ' string' => undef,
> 'value_2' => 'a simple',
> '--option' => 'value_1'
> };
>
> :-|... Maybe i could avoid this mess (and take me to an easy
> parsing) using a space separator instead of ','...
>
> Thank you all! :-)
> ff0000
Personally, I'd use a module that is designed for retrieving command
line options.
Getopt::Long
http://search.cpan.org/~jv/Getopt-Long-2.37/lib/Getopt/Long.pm
Getopt::Simple
http://search.cpan.org/~rsavage/Getopt-Simple-1.49/lib/Getopt/Simple.pm
------------------------------
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 1435
***************************************
