[29673] in Perl-Users-Digest
Perl-Users Digest, Issue: 917 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Oct 9 00:09:37 2007
Date: Mon, 8 Oct 2007 21:09:05 -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 Mon, 8 Oct 2007 Volume: 11 Number: 917
Today's topics:
an exe (generated by pp) then using ShellExecute to cat <mluvw47@gmail.com>
Re: an exe (generated by pp) then using ShellExecute to <ben@morrow.me.uk>
Re: Extended regexes - "(?<...)" construct. <paduille.4061.mumia.w+nospam@earthlink.net>
Re: how to do operation on a mapped drive <nitindutt2005@gmail.com>
Re: line 16 <zaxfuuq@invalid.net>
Re: line 16 <zaxfuuq@invalid.net>
Re: Perl on WinXP: transliteration produces different r <tadmc@seesig.invalid>
Re: Perl on WinXP: transliteration produces different r <dummy@example.com>
Profiling Perl with better granularity than Devel::DPro <clint.olsen@gmail.com>
Re: Profiling Perl with better granularity than Devel:: xhoster@gmail.com
Re: Profiling Perl with better granularity than Devel:: <clint.olsen@gmail.com>
Re: Profiling Perl with better granularity than Devel:: <ben@morrow.me.uk>
Re: Regex problem <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 08 Oct 2007 13:20:22 -0700
From: Mav <mluvw47@gmail.com>
Subject: an exe (generated by pp) then using ShellExecute to catch the error
Message-Id: <1191874822.753854.252190@d55g2000hsg.googlegroups.com>
Hi, all
how do I return error from a pl script(convert into .exe) when it
is called by ShellExecute.
I have a small helloworld.pl program that I used pp(Par-Packer) to
convert that become an helloworld.exe
helloworld.pl is very simple, just like below:
use Win32::Registry;
my $name;
my $error = 0;
$! = 0; #first clear $! from previous error code
$::HKEY_LOCAL_MACHINE->Open("SOFTWARE\\XYZ\\Configurationn",
$config);
#check see if the XYZ software is install.
if ($!) {
$error = 100
return fail; } #Is that how to return error to another program on
perl???
else
{ #continue doing something
}
Now on VC++ my progam call app.exe
When I tried to call my helloworld.exe
#this is app.exe
ShellExecute(NULL,"open","helloworld.exe", "","", SW_SHOW );
how to check if any error code get return by helloworld.exe (if it
got error how can I get the error code 100)?
Thanks,
Mav
------------------------------
Date: Tue, 9 Oct 2007 03:45:25 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: an exe (generated by pp) then using ShellExecute to catch the error
Message-Id: <5j6rt4-cfl1.ln1@osiris.mauzo.dyndns.org>
Quoth Mav <mluvw47@gmail.com>:
> Hi, all
> how do I return error from a pl script(convert into .exe) when it
> is called by ShellExecute.
>
> I have a small helloworld.pl program that I used pp(Par-Packer) to
> convert that become an helloworld.exe
> helloworld.pl is very simple, just like below:
>
> use Win32::Registry;
Where is
use strict;
use warnings;
> my $name;
> my $error = 0;
> $! = 0; #first clear $! from previous error code
> $::HKEY_LOCAL_MACHINE->Open("SOFTWARE\\XYZ\\Configurationn",
> $config);
>
> #check see if the XYZ software is install.
> if ($!) {
> $error = 100
> return fail; } #Is that how to return error to another program on
> perl???
Err... no. Where did you get that idea from? Did you even try it?
> else
> { #continue doing something
> }
>
> Now on VC++ my progam call app.exe
> When I tried to call my helloworld.exe
>
> #this is app.exe
> ShellExecute(NULL,"open","helloworld.exe", "","", SW_SHOW );
>
> how to check if any error code get return by helloworld.exe (if it
> got error how can I get the error code 100)?
You can set helloworld's exit status with the exit Perl builtin. How you
would then go about retrieving this from ShellExecute is rather beyond
me... Is there a good reason you can't use system() or CreateProcess()
from C++?
Ben
------------------------------
Date: Mon, 08 Oct 2007 16:12:19 -0500
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: Extended regexes - "(?<...)" construct.
Message-Id: <13gl7bnavh0bo46@corp.supernews.com>
On 10/08/2007 12:41 PM, Cloink wrote:
> Can anyone tell me why my version of Perl won't compile a so-called
> positive lookbehind assertion.
>
> Specifically, I want to strip JavaScript comments from a file,
> [...]
> But the perl compiler tells me it doesn't understand:-
> Sequence (?<[...) not recognized in regex; [line cont..]
> marked by <-- HERE in m/(?<[ <-- HERE ^\\])//.*$/
> [...]
Look closely at "perldoc perlre". (?< ...) is not supported. You can use
one of these:
(?<= ...)
(?<! ...)
------------------------------
Date: Tue, 09 Oct 2007 02:10:42 -0000
From: andy <nitindutt2005@gmail.com>
Subject: Re: how to do operation on a mapped drive
Message-Id: <1191895842.416115.28340@k79g2000hse.googlegroups.com>
On Oct 8, 8:48 pm, Ron Bergin <r...@i.frys.com> wrote:
> On Oct 8, 4:20 am, andy <nitindutt2...@gmail.com> wrote:
>
>
>
> > I have a remote server and I have mapped one drive from that remote
> > server into my local machine to access a perticular directory in that.
>
> > But I have to restart my local machine again and again. So again i
> > have to reconnect to the mapped drive by giving the userid and
> > password.
>
> > As I have to copy a file from that mapped drive and run that file on
> > the local machine after restarting the local machine.
>
> > The above process i have to do for each new file added into that
> > mapped drive.
> > So the steps are:
> > 1: detect the file added to the mapped drive.
> > 2: copy to the local machine.
> > 3: restart the local machine.
> > 4: Run that copied file.
> > 5: do the same process continuously so that each time a new file is
> > added to the mapped drive it will detect, copy the same file and
> > restart the machine.
>
> > How can this be done using perl.
>
> Why do you need to reboot your computer each time you copy a file?
>
> Please make an attempt at writing the script then post it and specific
> questions when you have a problem and we'll be happy to help.
>
> If you need/want someone to write it for you, then you may want to
> check out:http://www.rentacoder.com/RentACoder/default.asp
No its not like that. I am done with the accessing the mapped drive
at the first instant, and copied to local machine.
But how to restart the machine using script and if machine is
restarted manually just to check the script I am not able to access
the mapped drive as I will again have to give the userID and password.
That's the problem i am facing.
I mentioned the whole task to give the exact details of the restart
thing.
I thought like there will be some other way to do it easily. And i
don't want the whole script. I want the idea to approch in a easy
manner.
------------------------------
Date: Mon, 8 Oct 2007 18:57:16 -0700
From: "Wade Ward" <zaxfuuq@invalid.net>
Subject: Re: line 16
Message-Id: <0emdnaDK28R4TJfanZ2dnUVZ_uCinZ2d@comcast.com>
"Ron Bergin" <rkb@i.frys.com> wrote in message
news:1191371173.703572.246450@50g2000hsm.googlegroups.com...
> On Oct 2, 3:49 pm, "Wade Ward" <zaxf...@invalid.net> wrote:
>> #!/usr/bin/env perl
> Your shebang line indicates that you're on some form of *nix, but your
> reference to perl.exe would indicate that you're on Windows. Which is
> it? If you're on *nix, try changing your shebang line to point
> directly to the perl binary and see if that makes a difference.
>
I'm running xp and using the command line of a dos window. What would be
better?
--
wade ward
"Your boyfriend is not my boyfriend, doll."
------------------------------
Date: Mon, 8 Oct 2007 21:25:46 -0700
From: "Wade Ward" <zaxfuuq@invalid.net>
Subject: Re: line 16
Message-Id: <btednf6zj6QpaZfanZ2dnUVZ_vShnZ2d@comcast.com>
"Jim Gibson" <jgibson@mail.arc.nasa.gov> wrote in message
news:021020071728402299%jgibson@mail.arc.nasa.gov...
> In article <-9CdnVfbnvufIJ_anZ2dnUVZ_jGdnZ2d@comcast.com>, Wade Ward
> <zaxfuuq@invalid.net> wrote:
>> q3) Why does perl.exe not like line 16? I've correceted this before but
>> forget how. Thanks in advance.
>
> Not sure which line is 16. However, the documentation of Net::NNTP says
> methods that are supposed to return a value will return undef on
> failure. Therefore, you need to test the return value of newnews()
> before trying to dereference it as an array:
>
> die "Failed to retrieve message ids\n" unless defined $msg_ids_ref;
>
Testing for return values is a bit more than my current perl game. Thanks
for the heads-up.
--
wade ward
"Your boyfriend is not my boyfriend, doll."
------------------------------
Date: Mon, 8 Oct 2007 17:48:43 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Perl on WinXP: transliteration produces different results on different machines
Message-Id: <slrnfglcub.rpn.tadmc@tadmc30.sbcglobal.net>
hh <hh@hh.phys.gwu.edu> wrote:
> On 10/8/2007 2:43 PM, hh wrote:
>> $string = ~ tr/A-Z/a-z/;
>> I get
>>
>> ABCxyz
>> 4294967295
> Never mind, I found the error.
If you had enabled warnings, then perl would have found it *for you*.
You should always enable warnings when developing Perl code.
> Somehow I had erroneously inserted a
> blank space into the binding operator (=~) in the code for machine 2
> (reproduced above) which was not present in the code for machine 1.
>
> I knew it was a trivial error.
Your trivial error was not enabling warnings...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 08 Oct 2007 21:46:28 GMT
From: "John W. Krahn" <dummy@example.com>
Subject: Re: Perl on WinXP: transliteration produces different results on different machines
Message-Id: <UyxOi.10736$Cj1.6443@edtnps90>
hh wrote:
> I use the ActiveState Perl installation 5.8.8 (build 822) on two
> different Windows XP machines. The following simple code
>
> $string = "ABCxyz";
> print "$string\n";
> $string = ~ tr/A-Z/a-z/;
> print "$string\n";
>
> produces different results on the two machines. On machine 1, I obtain
>
> ABCxyz
> abcxyz
>
> as it should be, and on machine 2, I get
>
> ABCxyz
> 4294967295
>
> Any idea what's going? --- I presume it'll be something rather trivial
> since I am a Perl novice, but searching around everywhere I haven't been
> able to find anything.
Why not just use:
$string = lc $string;
on both machines?
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: Mon, 08 Oct 2007 16:22:13 -0500
From: Clint Olsen <clint.olsen@gmail.com>
Subject: Profiling Perl with better granularity than Devel::DProf
Message-Id: <slrnfgl7s5.2p2n.clint.olsen@belle.0lsen.net>
Hi:
I have managed to get a profile with Devel::DProf, and as I suspected, my
REs from one subroutine are taking the most time, however, I would like to
know if it's possible to get a bit more information than that. For
example, finding out if any of my REs in particular are inefficient in some
way would be helpful.
I ran VTune just for giggles, and I found that I am spending most of my
time in memcpy. I was curious why that was, so I ran callgraph profiling
and got the following execution graph:
main->perlrun->Perl_runops->Perl_regexec->Perl_savepvn->memcpy
I tried to do a little Googlin' to figure out what savepn is all about, but
I wasn't able to dig up much from reading perldebguts.
So, I've got two profiles, one that's a bit too general, and one that is
detailed but so low-level I am not sure how to easily relate it to my Perl
source code.
Any suggestions?
Thanks,
-Clint
------------------------------
Date: 08 Oct 2007 21:44:34 GMT
From: xhoster@gmail.com
Subject: Re: Profiling Perl with better granularity than Devel::DProf
Message-Id: <20071008174437.056$3c@newsreader.com>
Clint Olsen <clint.olsen@gmail.com> wrote:
> Hi:
>
> I have managed to get a profile with Devel::DProf, and as I suspected, my
> REs from one subroutine are taking the most time, however, I would like
> to know if it's possible to get a bit more information than that. For
> example, finding out if any of my REs in particular are inefficient in
> some way would be helpful.
>
> I ran VTune just for giggles, and I found that I am spending most of my
> time in memcpy. I was curious why that was, so I ran callgraph profiling
> and got the following execution graph:
>
> main->perlrun->Perl_runops->Perl_regexec->Perl_savepvn->memcpy
>
> I tried to do a little Googlin' to figure out what savepn is all about,
> but I wasn't able to dig up much from reading perldebguts.
>
> So, I've got two profiles, one that's a bit too general, and one that is
> detailed but so low-level I am not sure how to easily relate it to my
> Perl source code.
>
> Any suggestions?
What is your goal? If you just want to figure out which one out of several
regexes in that one subroutine is the culprit, you could use
Devel::SmallProf. I'm generally not all that fond of SmallProf, but this
is the kind of thing it could work well for. Sometimes it dramatically
increases the program's run time so you may want to profile a reduced input
set to shorten the profiling time, if that is possible.
Or you could move each regex into a separate dummy subroutines so that
DProf can pick them up. Or just comment out each regex, one at a time
or in a binary search pattern (assuming you can do so without affecting
downstream execution) and see which one makes the run time drop.
Or you could look at the regex and, knowing what kind if input they
typically operate on, take an educated guess as to which one would be
likely to be doing an exponential amount of backtracking. I'm not sure I
could explain in a compact way how to do this, but usually I know it when I
see it.
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: Mon, 08 Oct 2007 16:59:38 -0500
From: Clint Olsen <clint.olsen@gmail.com>
Subject: Re: Profiling Perl with better granularity than Devel::DProf
Message-Id: <slrnfgla2a.2p2n.clint.olsen@belle.0lsen.net>
On 2007-10-08, xhoster@gmail.com <xhoster@gmail.com> wrote:
> What is your goal? If you just want to figure out which one out of
> several regexes in that one subroutine is the culprit, you could use
> Devel::SmallProf. I'm generally not all that fond of SmallProf, but this
> is the kind of thing it could work well for. Sometimes it dramatically
> increases the program's run time so you may want to profile a reduced
> input set to shorten the profiling time, if that is possible.
The goal is just checking that I'm not shooting myself in the foot for any
reason. This thing is only going to get slower as I continue to add code,
so I was just checkpointing my effort so far. My parsing takes on the
order of 10 seconds with my current input set, so I'm all set for runtime
at the moment.
> Or you could move each regex into a separate dummy subroutines so that
> DProf can pick them up. Or just comment out each regex, one at a time or
> in a binary search pattern (assuming you can do so without affecting
> downstream execution) and see which one makes the run time drop.
Yeah, I'd have to probably split them up into subs in order to get what I
want. Since this is a lexer, I cannot afford to disable some patterns
and have things still work. Of course, these kinds of transformations are
very invasive and I'd spend quite a bit of time getting it working right.
The problem with these kinds of programs is that they are a challenge to
get working right (and well), and they are very brittle.
> Or you could look at the regex and, knowing what kind if input they
> typically operate on, take an educated guess as to which one would be
> likely to be doing an exponential amount of backtracking. I'm not sure I
> could explain in a compact way how to do this, but usually I know it when
> I see it.
Yeah, I already did this for a couple of more difficult RE's. I printed
out debug traces in (?{ }) blocks so it became clear when they were
backtracking, and I felt the pattern should match without it.
Thanks,
-Clint
------------------------------
Date: Tue, 9 Oct 2007 04:02:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Profiling Perl with better granularity than Devel::DProf
Message-Id: <ui7rt4-6kl1.ln1@osiris.mauzo.dyndns.org>
Quoth Clint Olsen <clint.olsen@gmail.com>:
>
> I have managed to get a profile with Devel::DProf, and as I suspected, my
> REs from one subroutine are taking the most time, however, I would like to
> know if it's possible to get a bit more information than that. For
> example, finding out if any of my REs in particular are inefficient in some
> way would be helpful.
>
> I ran VTune just for giggles, and I found that I am spending most of my
> time in memcpy. I was curious why that was, so I ran callgraph profiling
> and got the following execution graph:
>
> main->perlrun->Perl_runops->Perl_regexec->Perl_savepvn->memcpy
Just out of interest: which version of Perl is this? 5.8.8 doesn't have
a Perl_regexec, though it does have a Perl_regexec_flags and a
Perl_pregexec.
> I tried to do a little Googlin' to figure out what savepn is all about, but
> I wasn't able to dig up much from reading perldebguts.
The Perl_* functions are documented in perlapi (perldebguts is for the
internals of the Perl-level debugger). Perl_savepvn is a simple
string-copy function. AFAICT, the only time it is called directly from
Perl_regexec_flags is when populating the $N match variables (and $`,
$', $&; but you aren't using those, are you? Check if necessary with
Devel::SawAmpersand) so you may want to see if you can reduce the number
of sets of capturing parens.
Ben
------------------------------
Date: Mon, 8 Oct 2007 17:45:10 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Regex problem
Message-Id: <slrnfglcnm.rpn.tadmc@tadmc30.sbcglobal.net>
[ f-up set to a newsgroup that I participate in. ]
Lew <lew@lewscanon.com> wrote:
>> Hendrik Maryns (hendrik_maryns@despammed.com) wrote on VCLI September
>> MCMXCIII in <URL:news:fed8ua$v7n$1@newsserv.zdv.uni-tuebingen.de>:
>> ** (This is in Java, but the regex is general, therefore x-post to
>> ** c.l.p.m., f-up to c.l.j.h.)
^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^
> Abigail wrote:
>> I don't read the latter, so I won't post just there. Followups set to
^^^^^^^^^^
^^^^^^^^^^
>> clpm though.
>
> But the OP /does/ read clj.help, and pointed out that his problem is in Java,
And he will see Abigail's helpful answer there.
So what's the problem?
> so redirecting the answers away from clj.help is pure arrogance.
He did not redirect answers away!
His post containing an answer was posted to the newsgroup that
the OP asked for.
Abigail does not participate in clj.help, and so won't
be able to see any followups to his post.
Dumping stuff into a newsgroup you do not read is arrogance.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
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 917
**************************************
