[28283] in Perl-Users-Digest
Perl-Users Digest, Issue: 9647 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 25 18:06:10 2006
Date: Fri, 25 Aug 2006 15:05:09 -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 Fri, 25 Aug 2006 Volume: 10 Number: 9647
Today's topics:
Re: DBI Performance Issues xhoster@gmail.com
Re: Improved with a hatchet? anno4000@radom.zrz.tu-berlin.de
Re: Improved with a hatchet? <nobull67@gmail.com>
Re: Improved with a hatchet? <nobull67@gmail.com>
Re: Improved with a hatchet? <nobull67@gmail.com>
Re: Improved with a hatchet? <bill@ts1000.us>
Re: Improved with a hatchet? <glennj@ncf.ca>
Re: Improved with a hatchet? xhoster@gmail.com
Re: Improved with a hatchet? <someone@example.com>
Re: Match regular expression from LEFT to right <fritz-bayer@web.de>
Re: Match regular expression from LEFT to right anno4000@radom.zrz.tu-berlin.de
Re: Most useful standard module? <DJStunks@gmail.com>
Re: Prevent multiple instances of a script to launch <ced@blv-sam-01.ca.boeing.com>
Re: read file backwards <benmorrow@tiscali.co.uk>
Re: regular expression variables under debugger <klaus03@gmail.com>
Re: regular expression variables under debugger <wlcna@nospam.com>
Re: regular expression variables under debugger <mritty@gmail.com>
SOAP::Lite serializer for xsd:anyURI iamdannywa@gmail.com
Re: warnings (was Re: Most useful standard module?) (Chris Richmond - MD6-FDC ~)
Re: warnings (was Re: Most useful standard module?) <rvtol+news@isolution.nl>
Re: warnings (was Re: Most useful standard module?) <tadmc@augustmail.com>
Re: warnings (was Re: Most useful standard module?) (Chris Richmond - MD6-FDC ~)
Re: Win32::GUI and Scrolling Text <jackbarnett@gmail.com>
Re: WinNT ActiveState STDERR and STDOUT <ThomasKratz@REMOVEwebCAPS.de>
Re: xslt ? <surfunbear@yahoo.com>
Re: xslt ? <mgarrish@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 25 Aug 2006 17:56:42 GMT
From: xhoster@gmail.com
Subject: Re: DBI Performance Issues
Message-Id: <20060825135737.635$fP@newsreader.com>
"Chris H." <chris@thezengarden.net> wrote:
> im currently working on an issue for work, in which processing of a pipe
> delimited text file consisting of 356,400 lines of data with 19 fields in
> each row.
>
> the issue that i am having is not the performance of reading and
> splitting this data, but in writing to the database. using
> dbi/dbd::mysql, using 'localhost' as the server the script connects to i
> get the following results:
>
> > time ./ushbh-dev.pl hbh.txt
> Reading input file - 08/25/06 10:19:09
> Updating us_hourly table - 08/25/06 10:19:09
> 1000 records processed.
>
> real 0m1.096s
> user 0m0.424s
> sys 0m0.008s
>
> ------------------------
>
> using 'servername.tld' from a remote machine, i get the following
> performance:
>
> > time ./ushbh-dev.pl hbh.txt
> Reading input file - 08/25/06 10:17:49
> Updating us_hourly table - 08/25/06 10:17:49
> 1000 records processed.
>
> real 1m11.606s
> user 0m0.250s
> sys 0m0.034s
>
> ------------------------
How fast is your network connection? I see barely any change in
performance at all between local and remote.
> the issue seems to be with remote connections either through the dbi
> module, or the dbd::mysql driver.
I would suggest it is at a lower lever, at the network or at the compiled
binaries that DBD::mysql links against. Have you implemented the same
thing in another language (C, Java, Python) and seen better performance?
If not, I doubt your problem has anything to do with Perl or perl modules
per se.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 25 Aug 2006 15:29:38 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Improved with a hatchet?
Message-Id: <4l8jb2Fp50iU1@news.dfncis.de>
Bill H <bill@ts1000.us> wrote in comp.lang.perl.misc:
> I am using the following snippet of code to rotate a list starting at a
> random postion and it seems to run real slow (it works the way I want
> it to), can someone tell me how it can be improved?
>
> sub RotateList
> {
> my $results = "";
> my $srq = rand(@rotquest);
> my $i = 0;
> my $j = 0;
> for($i = 0;$i < @rotquest;$i++)
> {
> $j = $srq;
> $srq++;
> if ($srq >= @rotquest){$srq = 0;}
> $results .= $rotquest[$j];
> }
> return ($results);
> }
>
>
> And here is how I enter the routine:
[example snipped, useless because the output is missing]
> I am not concerned that it isn't returning a list since I just then
> dump the results out to a web page.
You could as well stringify the list and dump that. A routine that
promises to rotate a list should return a list, not a string. Also,
Perl has list manipulating functions that make the task very easy,
but those return lists.
While we're at it, a sub should also take parameters (the list to
rotate, the number of steps to rotate), not and not rely on global
variables or generate parameters internally. With these changes,
plus some internal cleanup your routine becomes
sub RotateList {
my ( $srq, @rotquest) = @_;
my @results;
for( 1 .. @rotquest )
{
my $j = $srq;
$srq++;
if ($srq >= @rotquest){$srq = 0;}
push @results, $rotquest[$j];
}
return (@results);
}
Your routine is slow because it moves each element at a time. Perl has
builtins that deal with lists and parts of lists as a whole. Since
rotation essentially means "cut the list in two and swap the parts"
They are more suited to the task. Here are some examples:
# using splice() to extract the parts and push() to swap them
sub RotateList1 {
my ( $srq, @rotquest) = @_;
push @rotquest, splice @rotquest, 0, $srq;
@rotquest;
}
# list slices to extract the parts, list concatenation to swap them
sub RotateList2 {
my ( $srq, @rotquest) = @_;
( @rotquest[ $srq .. $#rotquest], @rotquest[ 0 .. $srq - 1]);
}
# generate a list of swapped indices arithmetically. a list slice
# establishes the new order
sub RotateList3 {
my ( $srq, @rotquest) = @_;
@rotquest[ map $_ % @rotquest, $srq .. $srq + $#rotquest];
}
Anno
------------------------------
Date: 25 Aug 2006 08:31:31 -0700
From: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: Improved with a hatchet?
Message-Id: <1156519891.022070.232590@m79g2000cwm.googlegroups.com>
Glenn Jackman wrote:
> At 2006-08-25 10:29AM, "Bill H" wrote:
> > it seems to run real slow (it works the way I want
> > it to), can someone tell me how it can be improved?
> sub RotateList
> {
> my @list = @_;
> my $index = int rand $#list;
> return @list[$index+1 .. $#list], @list[0 .. $index];
> }
Since we're optomising for speed I'd get rid of the redundant @list
sub RotateList
{
my $index = int rand $#_;
return @_[$index+1 .. $#list, 0 .. $index];
}
------------------------------
Date: 25 Aug 2006 08:38:02 -0700
From: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: Improved with a hatchet?
Message-Id: <1156520282.725737.250730@h48g2000cwc.googlegroups.com>
Glenn Jackman wrote:
> return splice(@list, $index+1), @list
Whilst that's likely to be fast and efficient and give the right result
it still gives me an uneasy feeling that it's behaviour is, strictly
speaking, undefined and could, at least in principle, change in a
future release.
------------------------------
Date: 25 Aug 2006 08:47:50 -0700
From: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: Improved with a hatchet?
Message-Id: <1156520870.218366.286960@b28g2000cwb.googlegroups.com>
Brian McCauley wrote:
> Glenn Jackman wrote:
> > At 2006-08-25 10:29AM, "Bill H" wrote:
> > > it seems to run real slow (it works the way I want
> > > it to), can someone tell me how it can be improved?
>
> > sub RotateList
> > {
> > my @list = @_;
> > my $index = int rand $#list;
> > return @list[$index+1 .. $#list], @list[0 .. $index];
> > }
>
> Since we're optomising for speed I'd get rid of the redundant @list
>
> sub RotateList
> {
> my $index = int rand $#_;
> return @_[$index+1 .. $#list, 0 .. $index];
> }
Oops, the OP wanted a string... (oh, and there was a typo above).
sub RotateList
{
my $index = int rand $#_;
return join '', @_[$index+1 .. $#_, 0 .. $index];
}
Actually rather than pass a list to subrouine it's usually more
efficient to pass an arrayref.
sub RotateList
{
my $list = shift;
my $index = int rand $#$list;
return join '', @$list[$index+1 .. $#$list, 0 .. $index];
}
------------------------------
Date: 25 Aug 2006 09:35:46 -0700
From: "Bill H" <bill@ts1000.us>
Subject: Re: Improved with a hatchet?
Message-Id: <1156523746.557644.314010@m79g2000cwm.googlegroups.com>
Brian McCauley wrote:
> Brian McCauley wrote:
> > Glenn Jackman wrote:
> > > At 2006-08-25 10:29AM, "Bill H" wrote:
> > > > it seems to run real slow (it works the way I want
> > > > it to), can someone tell me how it can be improved?
> >
> > > sub RotateList
> > > {
> > > my @list = @_;
> > > my $index = int rand $#list;
> > > return @list[$index+1 .. $#list], @list[0 .. $index];
> > > }
> >
> > Since we're optomising for speed I'd get rid of the redundant @list
> >
> > sub RotateList
> > {
> > my $index = int rand $#_;
> > return @_[$index+1 .. $#list, 0 .. $index];
> > }
>
> Oops, the OP wanted a string... (oh, and there was a typo above).
>
> sub RotateList
> {
> my $index = int rand $#_;
> return join '', @_[$index+1 .. $#_, 0 .. $index];
> }
>
> Actually rather than pass a list to subrouine it's usually more
> efficient to pass an arrayref.
>
> sub RotateList
> {
> my $list = shift;
> my $index = int rand $#$list;
> return join '', @$list[$index+1 .. $#$list, 0 .. $index];
> }
Brian, I used your 1st example and will stick with a list instead of
making it a string. I have to make one change cause your example
wouldn't start on the 1st element (ie not rotate it). Here is what I
used:
sub RotateList
{
my $index = int rand $#_;
return join '', @_[$index .. $#_, 0 .. $index - 1];
}
Thanks to everyone for the help!
Bill H
------------------------------
Date: 25 Aug 2006 16:51:48 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: Improved with a hatchet?
Message-Id: <slrneeual4.kj9.glennj@smeagol.ncf.ca>
At 2006-08-25 11:38AM, "Brian McCauley" wrote:
> Glenn Jackman wrote:
>
> > return splice(@list, $index+1), @list
>
> Whilst that's likely to be fast and efficient and give the right result
> it still gives me an uneasy feeling that it's behaviour is, strictly
> speaking, undefined and could, at least in principle, change in a
> future release.
How is it undefined? The splice docs say:
Removes the elements designated by OFFSET and LENGTH
from an array, and replaces them with the elements
of LIST, if any. In list context, returns the
elements removed from the array.
--
Glenn Jackman
Ulterior Designer
------------------------------
Date: 25 Aug 2006 17:59:51 GMT
From: xhoster@gmail.com
Subject: Re: Improved with a hatchet?
Message-Id: <20060825140046.272$yU@newsreader.com>
xx087+news@ncf.ca wrote:
> At 2006-08-25 11:38AM, "Brian McCauley" wrote:
> > Glenn Jackman wrote:
> >
> > > return splice(@list, $index+1), @list
> >
> > Whilst that's likely to be fast and efficient and give the right
> > result it still gives me an uneasy feeling that it's behaviour is,
> > strictly speaking, undefined and could, at least in principle, change
> > in a future release.
>
> How is it undefined? The splice docs say:
> Removes the elements designated by OFFSET and LENGTH
> from an array, and replaces them with the elements
> of LIST, if any. In list context, returns the
> elements removed from the array.
Is the second occurence of @list in the return statement evaluated before
or after the splice is done to it? In other words, is the comma between
splice(...),@list as sequence point or not?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 25 Aug 2006 19:17:23 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Improved with a hatchet?
Message-Id: <71IHg.17568$Ch.16495@clgrps13>
Bill H wrote:
> I am using the following snippet of code to rotate a list starting at a
> random postion and it seems to run real slow (it works the way I want
> it to), can someone tell me how it can be improved?
>
> sub RotateList
> {
> my $results = "";
> my $srq = rand(@rotquest);
> my $i = 0;
> my $j = 0;
> for($i = 0;$i < @rotquest;$i++)
> {
> $j = $srq;
> $srq++;
> if ($srq >= @rotquest){$srq = 0;}
> $results .= $rotquest[$j];
> }
> return ($results);
> }
>
>
> And here is how I enter the routine:
>
> @rotquest = (
> qq~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED1" VALUE="An
> automobile manufacturer or dealer ">An automobile manufacturer or
> dealer<BR>~,
> qq~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED2" VALUE="A
> market research company">A market research company<BR>~,
> qq~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED3" VALUE="A
> newspaper or TV station">A newspaper or TV station<BR>~,
> qq~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED4" VALUE="An
> advertising agency">An advertising agency<BR>~);
> $q4 = &RotateList();
> $q4 .= qq~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED5"
> VALUE="None of the above">None of the above\n~;
>
> I am not concerned that it isn't returning a list since I just then
> dump the results out to a web page.
my @rotquest = (
q~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED1" VALUE="An automobile
manufacturer or dealer ">An automobile manufacturer or dealer<BR>~,
q~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED2" VALUE="A market research
company">A market research company<BR>~,
q~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED3" VALUE="A newspaper or TV
station">A newspaper or TV station<BR>~,
q~ <INPUT TYPE=CHECKBOX NAME="EMPLOYED4" VALUE="An advertising
agency">An advertising agency<BR>~
);
print splice( @rotquest, rand @rotquest ), @rotquest, q~ <INPUT
TYPE=CHECKBOX NAME="EMPLOYED5" VALUE="None of the above">None of the above\n~;
John
--
use Perl;
program
fulfillment
------------------------------
Date: 25 Aug 2006 09:16:46 -0700
From: "fritz-bayer@web.de" <fritz-bayer@web.de>
Subject: Re: Match regular expression from LEFT to right
Message-Id: <1156522606.892277.25310@74g2000cwt.googlegroups.com>
anno4000@radom.zrz.tu-berlin.de wrote:
> fritz-bayer@web.de <fritz-bayer@web.de> wrote in comp.lang.perl.misc:
> > Hi,
> >
> > lets say I have the following string:
> >
> > <tr> dfsdfre <tr>fsdsfd35gd <tr>khf758 <tr>afdga654jhuotj <input
> > type="text"> 67kfbs356</tr>sh tu65 </tr> hbrubs</tr>
> >
> > and I would like to capture the text before the <input...> until the
> > first <tr> and the text after until the first <tr> so that I get
> >
> > <tr>afdga654jhuotj <input type="text> 67kfbs356</tr>
> >
> > How would I do this?
> >
> > =~ m!<tr>.*?<input type="text">.*?<tr>!
> >
> > will only work capturing the first <tr> after the <input..>. The
> > problem is that I have to find a expression, which starts looking from
> > the right to the left of <input...>.
>
> Your explanation is confused about whether the closing part should
> be <tr> or </tr>. Please clear that up.
>
> Anno
Hi Anno,
this is just an example. Actually I'm not looking for a concrete
solution for this. It's just an example to illustrate my problem.
If I have a text which contains a lot of text for example. An in the
middle somewhere I have the phrase "this is the center of the text",
then how can I capture this sentence plus the 10 words preceeding and
following the sentence.
Or how could I caputre this sentece plus any text which preceeds this
sentence UNTIL the word "stopword" is matched. A "stopword.*?this is
the center of the text" can fail, if the word "stopword" is a common
word, which appears several times.
Maybe in this context my phrase matching from "right to left" becomes
more meaningfull?
Fritz
------------------------------
Date: 25 Aug 2006 21:36:48 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Match regular expression from LEFT to right
Message-Id: <4l98rgFtka2U1@news.dfncis.de>
fritz-bayer@web.de <fritz-bayer@web.de> wrote in comp.lang.perl.misc:
>
> anno4000@radom.zrz.tu-berlin.de wrote:
> > fritz-bayer@web.de <fritz-bayer@web.de> wrote in comp.lang.perl.misc:
> > > Hi,
> > >
> > > lets say I have the following string:
> > >
> > > <tr> dfsdfre <tr>fsdsfd35gd <tr>khf758 <tr>afdga654jhuotj <input
> > > type="text"> 67kfbs356</tr>sh tu65 </tr> hbrubs</tr>
> > >
> > > and I would like to capture the text before the <input...> until the
> > > first <tr> and the text after until the first <tr> so that I get
> > >
> > > <tr>afdga654jhuotj <input type="text> 67kfbs356</tr>
> > >
> > > How would I do this?
> > >
> > > =~ m!<tr>.*?<input type="text">.*?<tr>!
> > >
> > > will only work capturing the first <tr> after the <input..>. The
> > > problem is that I have to find a expression, which starts looking from
> > > the right to the left of <input...>.
> >
> > Your explanation is confused about whether the closing part should
> > be <tr> or </tr>. Please clear that up.
> >
> > Anno
>
> Hi Anno,
>
> this is just an example. Actually I'm not looking for a concrete
> solution for this. It's just an example to illustrate my problem.
Right. Because it is meant to illustrate the problem it is important
that you make it consistent.
Concrete solutions is all I have to offer. I don't think there is
a general solution to your backwards-matching problem. There may
well be individual solutions to special cases of it.
> If I have a text which contains a lot of text for example. An in the
> middle somewhere I have the phrase "this is the center of the text",
> then how can I capture this sentence plus the 10 words preceeding and
> following the sentence.
I'll use a somewhat simplistic definition of "word": any sequence of
non-spaces, optionally followed by a space, /\S+ ?/ in regex. This
will match $n words around "this is the center ":
my $text = "stop this and stop that and " .
"this is the center " .
"and stop stop again";
my $n = 3;
my ( $extr) = $text =~
/((?:\S+ ?){$n}this is the center (?:\S+ ?){$n})/;
print $extr || '-failed-', "\n";
That prints three words on both sides of "this is the center "
stop that and this is the center and stop stop
> Or how could I caputre this sentece plus any text which preceeds this
> sentence UNTIL the word "stopword" is matched. A "stopword.*?this is
> the center of the text" can fail, if the word "stopword" is a common
> word, which appears several times.
Using "stop" for "stopword" and the same text from above:
( $extr) = $text =~ /.*(stop.*this is the center.*?stop)/;
print $extr || '-failed-', "\n";
prints the nearest pair of "stop"s surrounding "this is the center"
plus intervening text:
stop that and this is the center and stop
These are rough solutions which may be good enough for some
applications but not for others. Refining them while sticking
to the principle that one regex must do it is usually *not*
worth the while. If a robust, flexible solution is needed,
it is better to do the work in several steps.
Anno
------------------------------
Date: 25 Aug 2006 12:03:15 -0700
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: Most useful standard module?
Message-Id: <1156532595.847486.170880@h48g2000cwc.googlegroups.com>
Davy wrote:
> Hi all,
>
> I have used Getopt::Std and File::Find. I found standard module useful.
>
> Is there any artical summarize the most useful standard module?
I vote for Miss Storable. She looked INCREDIBLE in that swimsuit =p~
-jp
------------------------------
Date: Fri, 25 Aug 2006 20:39:27 GMT
From: Charles DeRykus <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Prevent multiple instances of a script to launch
Message-Id: <J4KMpq.LKA@news.boeing.com>
Philipp wrote:
> Hello
> I have written a Perl script (win32) and use it to drag&drop files on it
> for execution.
> Now if I drop multiple files at once, they are processed one after the
> other. But if I drop one file at a time, each starts a new perl
> interpreter and new script.
>
> Is there an easy way to prevent these new copies to start and instead
> queue the corresponding files in an already running script? (so they get
> executed sequentially and not in parallel)
>
One possible solution would be to write the files to a simple DBM and
delete DBM entries as the files are processed. The "master" instance
would do the processing after locking a sentinel file to prevent a
possible "master" race condition Subsequent "helper" instances of the
script would detect the lock and just add their files to the DBM before
exiting. The master could check for running helpers when the DBM emptied
out. Then, if helpers were still running, the master could sleep/loop
checking for DBM additions; if no helpers were running and the DBM was
empty, the master could unlock the sentinel and exit.
hth,
--
Charles DeRykus
------------------------------
Date: Thu, 24 Aug 2006 23:49:58 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: read file backwards
Message-Id: <m1n1s3-sgh.ln1@osiris.mauzo.dyndns.org>
Quoth Charlton Wilbur <cwilbur@mithril.chromatico.net>:
> Jim Gibson <jgibson@mail.arc.nasa.gov> writes:
>
> > I agree. It like people asking "I want to hammer a nail, but I don't
> > want to use a hammer." People who ask such questions should really
> > justify why they can't or won't use modules. Otherwise, they are just
> > wasting your time.
>
> The problem is, then they start justifying why, and you find out one
> of a couple things.
>
> * They're using a cut-rate web host, only have FTP access, and want a
> module that's compiled.
>
> * They're using Perl without the support of their organization, which
> means they can't officially ask for modules to be installed.
>
> * They have the false notion that modules are slow.
>
> Trying to convince people in any of these circumstances that they
> should use modules is a futile effort; once you've recommended the use
> of modules, the best you can do is move on.
Or, perhaps, point them in the direction of
pp -P -o look-ma-no-modules foo
? Requires PAR to be installed on the dev machine, but this shouldn't be
a problem. Of course, for XS modules it does something *truly* evil, and
it will make the script somewhat slower, but that's not our problem.
Ben
--
We do not stop playing because we grow old;
we grow old because we stop playing.
benmorrow@tiscali.co.uk
------------------------------
Date: 25 Aug 2006 11:17:34 -0700
From: "Klaus" <klaus03@gmail.com>
Subject: Re: regular expression variables under debugger
Message-Id: <1156529854.551742.93460@i3g2000cwc.googlegroups.com>
wlcna wrote:
> The offending code is essentially IDENTICAL to what I posted.
"essentially *identical*" is not the same as "*identical*"
> so I'm going to change the code right now to see what it thinks [...]
Good.
To change the code, I suggest you proceed by the following 11 points:
1.) Erase your memory about this problem (in your head, not on your
hard drive)
2.) Make a copy of the original, unchanged program on your hard drive
and load that copy into your favourite text editor
3.) Look at the following two lines of code in your program
wlcna wrote:
> 2: $str =~ /([a-z]*)s/;
> 3: $yes = $1;
you will notice that you are using $1 without checking whether or not
the match succeeded.
4.) fix that problem:
> 2: $str =~ /([a-z]*)s/ or die qq{No match in '$str'};
> 3: $yes = $1;
5.) add some prints to your code
: print '$str = ', unpack('H*', $str), "\n";
: $str =~ /([a-z]*)s/ or die qq{No match in '$str'};
: print '$1 = ', unpack('H*', $1), "\n";
: $yes = $1;
6.) Run the program twice: once with debugger, then without debugger.
7.) If the value in $1 is identical in both runs, with and without
debugger, then we're done and the problem is solved.
8.) If not, then strip-down (strategically remove) 10 - 20 lines of
code from your program, but do not touch the lines in question. (if
your program is very big, then you can delete more lines). Remember:
you are working with a copy of the original program.
9.) Again, run the stripped-down program twice: first with debugger,
then without debugger.
10.) If the value in $1 is identical in both runs, with and without
debugger, then *remember* what you have changed last in step 8.) --
That's what's caused the problem and we're done !
11.) If not, then strip down your program even further and go to step
8.) -- and don't forget: your program is getting smaller and smaller
with every step !
------------------------------
Date: Fri, 25 Aug 2006 18:48:04 GMT
From: "wlcna" <wlcna@nospam.com>
Subject: Re: regular expression variables under debugger
Message-Id: <EBHHg.3084$yO7.1357@newssvr14.news.prodigy.com>
"Paul Lalli" <mritty@gmail.com> wrote in message
news:1156515305.615509.68210@b28g2000cwb.googlegroups.com...
> Once again, I cannot duplicate your problem:
> $ perl -d
>
Yeah, you wouldn't be able to that way as I've pointed out. If my hunch
is correct about the problem, I should be able to have some reproducible
code shortly (as soon as I get a chance), but if you're curious now, you
can simply read the other part of the thread where I've detailed what I
think the problem is.
------------------------------
Date: 25 Aug 2006 11:53:02 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: regular expression variables under debugger
Message-Id: <1156531978.527597.109920@h48g2000cwc.googlegroups.com>
wlcna wrote:
> "Paul Lalli" <mritty@gmail.com> wrote in message
> news:1156515305.615509.68210@b28g2000cwb.googlegroups.com...
> > Once again, I cannot duplicate your problem:
> > $ perl -d
> >
>
> Yeah, you wouldn't be able to that way as I've pointed out. If my hunch
> is correct about the problem, I should be able to have some reproducible
> code shortly (as soon as I get a chance), but if you're curious now, you
> can simply read the other part of the thread where I've detailed what I
> think the problem is.
No, sorry, I have no interest in your conjectures. I do not mean to be
rude, but this is now bordering on the absurd - just post the program
that shows the bug!
Paul Lalli
------------------------------
Date: 25 Aug 2006 13:23:56 -0700
From: iamdannywa@gmail.com
Subject: SOAP::Lite serializer for xsd:anyURI
Message-Id: <1156537432.467556.15470@m79g2000cwm.googlegroups.com>
I had a SOAP funtion make a generic return of an untyped array which
consisted of a URL and a file path (for maintaining an image
repository). The function worked as expected until it encountered an
address (URL) that had multiple query parameters and thus a bare '&' in
the URL.
The SOAP::Lite serializer typed the content as anyURI just as you would
expect from teh documentation. However, the serializer did not encode
the '&' as '&' and the XML validation of the SOAP envelope failed.
Should the serializer of type anyURI entity encode to render valid XML?
I think so, but I cannot find any documentation to argue either way.
Here is a snippet of server code. it will showcase the problem I am
experiencing. In this example I type the return values. In my actual
webservice I allowed SOAP::Lite to type it and it will always type a
URL formatted string as anyURI.
CODE:::
BEGIN {
package SOAP_ImageMgr;
sub Hello {
my $self = shift;
my $badURI = 'http://www.com/cgi?text=Hello%20World&doit=Goodbye';
return (
SOAP::Data->type('anyURI')->value($badURI),
SOAP::Data->type('string')->value($badURI)
);
}
1;
}
use SOAP::Transport::HTTP;
our $srv = SOAP::Transport::HTTP::CGI->dispatch_to('SOAP_ImageMgr');
$srv->serializer->encoding();
$srv->handle();
Where to go from here?
------------------------------
Date: Fri, 25 Aug 2006 15:06:15 +0000 (UTC)
From: crichmon@filc9283.fm.intel.com (Chris Richmond - MD6-FDC ~)
Subject: Re: warnings (was Re: Most useful standard module?)
Message-Id: <ecn3l7$676$1@news01.intel.com>
In article <slrneepsnp.go5.tadmc@magna.augustmail.com>,
Tad McClellan <tadmc@augustmail.com> writes:
>"use warnings" is far superior to the -w switch.
>("use warnings" is far superior to the -w switch.)
Tad,
You've been doign this forever (me too) and I respect your opinion,
but *why* is "use warnings;" better than -w on line #1? If its so
you can disable warnings in certain places then that defeats the
requirement to enforce non-warnable code.
Here's another question. Why are 'my' variables immune to some
of the -w checks ('used only once' for example)?
I've been using perl in a huge project for ~12 years and started
with perl4. perl5 introduced use strict; which forces 'my' (or global)
on everything and at the same time breaking pieces of warnings.
Long ago, we packaged all subroutines to pseudo hide variables
from being global by default, used -w, and this has been very
successful. Its all procedural code. No OOP whackiness.
Thx, Chris
--
Chris Richmond | I don't speak for Intel & vise versa
------------------------------
Date: Fri, 25 Aug 2006 20:19:45 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: warnings (was Re: Most useful standard module?)
Message-Id: <ecnm3f.1g8.1@news.isolution.nl>
Chris Richmond - MD6-FDC ~ schreef:
> *why* is "use warnings;" better than -w on line #1?
See warnings (which mentions perllexwarn).
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Fri, 25 Aug 2006 14:40:42 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: warnings (was Re: Most useful standard module?)
Message-Id: <slrneeukhq.oqt.tadmc@magna.augustmail.com>
Chris Richmond - MD6-FDC ~ <crichmon@filc9283.fm.intel.com> wrote:
> In article <slrneepsnp.go5.tadmc@magna.augustmail.com>,
> Tad McClellan <tadmc@augustmail.com> writes:
>>"use warnings" is far superior to the -w switch.
>
>>("use warnings" is far superior to the -w switch.)
> but *why* is "use warnings;" better than -w on line #1?
Scoped warnings are better than global warnings for reasons similar
to why scoped variables are better than global variables.
> If its so
> you can disable warnings in certain places then that defeats the
> requirement to enforce non-warnable code.
You can disable only the offending warning with the pragma:
{ no warnings 'uninitialized';
# no seat belts here
}
If you are forced to use a non-warnings-clean module, the -w spews
a bunch of stuff that you have no control over, which "trains" you
to ignore warnings even if there might be a "real" one in amongst
all of the noise.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Fri, 25 Aug 2006 21:17:38 +0000 (UTC)
From: crichmon@filc9283.fm.intel.com (Chris Richmond - MD6-FDC ~)
Subject: Re: warnings (was Re: Most useful standard module?)
Message-Id: <ecnpdi$676$2@news01.intel.com>
In article <slrneeukhq.oqt.tadmc@magna.augustmail.com>,
Tad McClellan <tadmc@augustmail.com> writes:
>If you are forced to use a non-warnings-clean module, the -w spews
>a bunch of stuff that you have no control over, which "trains" you
>to ignore warnings even if there might be a "real" one in amongst
>all of the noise.
Oh, that sort of explains things. We treat warnings as fatal
errors. They *have* to be fixed or the code doesn't get released.
Thx, Chris
--
Chris Richmond | I don't speak for Intel & vise versa
------------------------------
Date: 25 Aug 2006 10:39:39 -0700
From: "jackbarnett@gmail.com" <jackbarnett@gmail.com>
Subject: Re: Win32::GUI and Scrolling Text
Message-Id: <1156527577.770730.25510@h48g2000cwc.googlegroups.com>
TK stuff is working.... this is what I'm trying to do (can't use tail
and that ulgy filehandler thing you got there):
Here is my code. basically I need the "dostuff" to run the entire
time, but looks like it's also fighting with MainLoop() [keeps locking
up application, not updating, etc]
Thoughts?
#!/usr/bin/perl
use Tk;
use IO::Handle;
use Sys::Hostname;
use strict;
my $main = MainWindow->new;
my $t = $main-> Scrolled('Text',
-wrap=>'none')->pack(-expand=>1);
my $file = "z.txt";
my $sleeptime=1;
my $hello = $main->Button(
-text => 'Hello, world',
-command => sub { &dostuff; } );
$hello->pack;
# unless (fork) { &dostuff(); }
MainLoop();
exit();
sub dostuff() {
open (FILE, "$file")
or die ("Can't open file: $file: $!\n");
for (;;) {
while ( <FILE> ) {
my $line=$_;
chomp($line);
print ("$line\n");
$t->insert('end',"$line\n");
$t->yview('end');
$t->see('end'); #same thing
$t->update();
}
sleep ($sleeptime);
FILE->clearerr();
}
close (FILE)
or warn ("Can't close file: $file: $!\n");
}
------------------------------
Date: Fri, 25 Aug 2006 17:19:12 +0200
From: Thomas Kratz <ThomasKratz@REMOVEwebCAPS.de>
Subject: Re: WinNT ActiveState STDERR and STDOUT
Message-Id: <44ef14f0$0$31168$bb690d87@news.main-rheiner.de>
addinall wrote:
> I'm having a problem and wondered if anyone else
> has come across something like this.
>
> I have a customer with a legacy NT4.0 system.
> A requirement came up to run several jobs in
> the background and capture the output of STDOUT
> and STDERR for later analysis.
>
> Code (example only)
>
> HELLO.BAT
> echo Hello World this is STDOUT
> This line will produce an error to STDERRR
> echo
>
> posix.pl
> #! perl -w
>
> use Proc::Background qw( timeout_system ) ;
> print("Hello World STDOUT from Perl") ;
> my @t = timeout_system( 5, "c:\\Perl\\bin\\HELLO.BAT") ;
As I understand from a quick glance at the docs for Proc::Background,
background processes are created through Win32::Process::Create like this:
Win32::Process::Create(
$os_obj,
$args[0],
"@args",
0,
NORMAL_PRIORITY_CLASS,
'.'
);
The 0 as 4th parameter means "don't inherit handles from callin process",
which means this process will not inherit STDOUT and STDERR from perl or
eventually the shell your script is running in.
Change this to use the standard system() function and it will.
But you can specify a different log file as
my @t = timeout_system( 5, 'c:\Perl\bin\HELLO.BAT >log2 2>&1') ;
Or you could file a change request to the author of Proc::Background to
make the flag configurable.
Thomas
--
$/=$,,$_=<DATA>,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~......>r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k^.-
------------------------------
Date: 25 Aug 2006 11:37:22 -0700
From: "surf" <surfunbear@yahoo.com>
Subject: Re: xslt ?
Message-Id: <1156531042.429271.109710@75g2000cwc.googlegroups.com>
Tad McClellan wrote:
> surf <surfunbear@yahoo.com> wrote:
> >
> > Tad McClellan wrote:
> >> surf <surfunbear@yahoo.com> wrote:
> >>
> >>
> >> > I'm not sure why anyone would want
> >> > to write a program of any sort in XML anyway ?
> >>
> >>
> >> One Reason:
> >>
> >> XSLT is optimized for machines rather than for humans.
> >>
> >>
> >>
> >> Let's haul this back on-topic:
> >>
> >> Contrast that with Perl, which is optimized for humans at the
> >> expense of the machine (throwing cycles and memory at a problem).
> >>
> >>
> >
> > I'm not an xslt expert, but you need to elaborate on that.
> ^^^^
> ^^^^
> No I don't.
>
>
> > Obviously
> > programming in assembly language is not very popular, although it might
> > be optimized for machines.
>
>
> I don't need to elaborate on what I said.
>
> I might need to elaborate on why XSLT is popular though.
>
> Here's my stab at it: platform independence.
>
>
I'd like to have a look at a complex xlst example if I could find one.
My suspicion is that people don't want to learn perl just to transform
xml,
although if you allready know perl, it would probably do a better job
and is available on most machines.
------------------------------
Date: 25 Aug 2006 14:44:26 -0700
From: "Matt Garrish" <mgarrish@gmail.com>
Subject: Re: xslt ?
Message-Id: <1156542266.330910.64880@b28g2000cwb.googlegroups.com>
Tad McClellan wrote:
> surf <surfunbear@yahoo.com> wrote:
> >
> > Matt Garrish wrote:
> >> surf wrote:
> >>
> >> > I had tried to work with XLST a few years ago. I got some simple stuff
> >> > to work, then I started playing with perl XML parsers and the xml:twig
> >> > module in perl. All of this stuff I really liked, so I forgot about
> >> > working with xlst which to me didn't seem like the way to go,
> >> > especially if it got very complex. I'm not sure why anyone would want
> >> > to write a program of any sort in XML anyway ?
> >> >
> >>
> >> You're so behind the times. Everyone is using RXParse for their XML
> >> these days. Be sure and tell your recruiter.
> >>
> >
> > Under jobs on boston craigslist I searched for xslt and got 222 hits,
> > I got none for RXParse. That doesn't mean it isn't great, just that no
> > one in boston is looking to hire anyone based on that unless it's a
> > tool that is part of some other application.
>
>
> Matt's post was an (inside) joke. He should have put a smiley in it.
>
> RXParse is an abomination of a hack, written by a troll that
> posts here from time to time.
>
Well, I didn't want to give away the joke. It sounded like he was
asking for some technical double-talk to bluff his way into jobs, and
without the smiley it might well have induced him to bring it up in
conversation. But since you guys ratted me out... ; )
Matt
------------------------------
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 V10 Issue 9647
***************************************
