[23603] in Perl-Users-Digest
Perl-Users Digest, Issue: 5810 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Nov 15 21:05:43 2003
Date: Sat, 15 Nov 2003 18:05:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 15 Nov 2003 Volume: 10 Number: 5810
Today's topics:
Re: access win32 from unix? <nospam@bigpond.com>
Re: accuracy problem <ewilhelm@somethinglike.sbcglobalDOTnet>
Re: accuracy problem <REMOVEsdnCAPS@comcast.net>
Re: accuracy problem <ewilhelm@somethinglike.sbcglobalDOTnet>
Re: ALRM weirdness in Perl 5.8.0 <nospam-abuse@ilyaz.org>
Re: arrange form data in same order as on form <REMOVEsdnCAPS@comcast.net>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: arrange form data in same order as on form <REMOVEsdnCAPS@comcast.net>
Re: arrange form data in same order as on form <noreply@gunnar.cc>
Re: binmode and the diamond operator (J. Romano)
Re: Chomp doesn't work for me <invalid-email@rochester.rr.com>
Re: Chomp doesn't work for me (Jay Tilton)
Re: Chomp doesn't work for me <REMOVEsdnCAPS@comcast.net>
Re: Chomp doesn't work for me <mikeflan@earthlink.net>
Re: Chomp doesn't work for me <mikeflan@earthlink.net>
Re: extracting Javascript from a web page (Malcolm Dew-Jones)
Re: regex to convert 1000000 -> 1,000,000 ? <REMOVEsdnCAPS@comcast.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 16 Nov 2003 09:19:55 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: access win32 from unix?
Message-Id: <12176620.zpJM3pVP1X@gregs-web-hosting-and-pickle-farming>
It was a dark and stormy night, and Mike managed to scribble:
> In article Toomey wrote:
>> It was a dark and stormy night, and Mike managed to scribble:
>>
>>> Given the need to monitor win32 (win2k and winxp) boxes from unix,
>>> and given that there are modules to access win32 performance
>>> and other data, and given that this data can be accessed accross
>>> the network, is there a way using perl to access this data
>>> from unix (i.e. a unix box asks a windows box how much disk
>>> space remains, etc)?
>>>
>>> Mike
>>
>> You can run most of the CPAN modules on Win2k/winxp.
>>
>> I was at a linux workshop yesterday & the sysdamin of a large retailer
>> had http://cygwin.com/ installed on every windows PC. Cygwin has most of
>> the unix tools available under windows & allows him to do all sorts of
>> remote admin.
>>
>> gtoomey
>>
>
> What I'm searching for is a way to query a windows registery,
> or the performance stats, or the services from unix across
> the network. I'm not searching for cygwin or if I can run
> a CPAN module on win32 itself.
>
> Mike
I would presume standard unix commands like 'df' are available with cygwin to show disk space. The output from df is easily parseable.
gtoomey
------------------------------
Date: Sun, 16 Nov 2003 00:10:14 GMT
From: Eric Wilhelm <ewilhelm@somethinglike.sbcglobalDOTnet>
Subject: Re: accuracy problem
Message-Id: <pan.2003.11.15.18.10.54.416604.1618@somethinglike.sbcglobalDOTnet>
On Sat, 15 Nov 2003 16:28:34 -0600, Jürgen Exner wrote:
>> Any way to fix this?
>
> Yes.
> Is is mentioned in any computer numerics class thou shalt never compare
> so-called real numbers (which are more aptly called floating point
> numbers) for equality. Instead check if they are within an epsilon range
> of each other.
Thanks, but I have no intention of comparing them directly. The problem
is that they will not be within the required epsilon range of each
other if the coordinates are not calculated with 128-bit precision.
I have long been aware of the advice to round numbers before trying to do
a comparison, etc, etc, but this is not a financial application and what
I have to make happen is that @ptB is halfway between @ptA and @ptC so
that an arc centered at @ptB can go through @ptA and @ptC in a piece of
external software which is using 'long double' for floating point numbers.
It seems from the INSTALL and README files in the perl source that perl
should be using 'long double' if configured as such, but the test does
not give the same results as C code which does use 'long double'
directly.
Thanks,
Eric
------------------------------
Date: Sat, 15 Nov 2003 18:12:55 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: accuracy problem
Message-Id: <Xns9434C399470E7sdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Eric Wilhelm <ewilhelm@somethinglike.sbcglobalDOTnet> wrote in
news:pan.2003.11.15.15.13.11.640507.1618@somethinglike.sbcglobalDOTnet:
> Anyone have similar experiences?
Oh yeah. Everyone who has ever used floating-point numbers has had this
problem.
> Any way to fix this?
Nope. It's a limitation of the precision of the hardware. It doesn't
matter if you use double-precision numbers, or quadruple, or whatever.
Some numbers simply are not representable in a finite mantissa/exponent
model.
> Rounding is not
> a solution, because the contents of @s and @f are the desired product,
> and the distance between them needs to be 2 * $r when computed with long
> doubles (i.e. the inaccuracy apparently happens in the addition as
> opposed to the distance calculation.)
Rounding is not a solution? Not even, say, rounding to the 12th decimal
place? Surely nothing you're doing can require that level of precision.
The simple truth is, you cannot reliably use == or != with floating-point
numbers. You must do some sort of "is this close enough" comparison on
your own. You have to decide what constitutes "close enough".
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP7bBMGPeouIeTNHoEQLf0wCg7A6oQOgdybi75AcRr9+bmr2PkVwAoJAY
6LcSvscd+oJBSKee0cX71BNA
=U1By
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 16 Nov 2003 00:25:54 GMT
From: Eric Wilhelm <ewilhelm@somethinglike.sbcglobalDOTnet>
Subject: Re: accuracy problem
Message-Id: <pan.2003.11.15.18.26.33.801363.1618@somethinglike.sbcglobalDOTnet>
On Sat, 15 Nov 2003 18:12:55 -0600, Eric J. Roode wrote:
> Rounding is not a solution? Not even, say, rounding to the 12th decimal
> place? Surely nothing you're doing can require that level of precision.
>
>
The issue is getting the calculations to resolve between cartesian
coordinates and trigonometric calculations. If I have an arc that has
been centered between two points and I calculate its endpoints, rounding
each coordinate (to any decimal place), they are not matching up to the
points that were averaged to get to the center point. While I am able to
sidestep the issue, it is causing problems in downstream programs which
are expecting higher precision.
> The simple truth is, you cannot reliably use == or != with
> floating-point numbers. You must do some sort of "is this close enough"
> comparison on your own. You have to decide what constitutes "close
> enough".
I have just realized that maybe I have what I was asking for:
0.375000000000000002 != 0.375 comes from the 5.8.0 custom build
0.375000000000004 != 0.375 comes from the 5.6.1 which has been installed
I guess the 'long double' is only 80 bits (somehow I cooked up the idea
that it was 128), but it is longer than the 64 bits that I was apparently
using before.
Now I have to setup a new installation with all of the libraries that were
being used (this problem came up in the middle of a lot of abstract and
complicated functions) and see if it solves the issue with the downstream
software.
Thanks,
Eric
------------------------------
Date: Sun, 16 Nov 2003 00:50:45 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: ALRM weirdness in Perl 5.8.0
Message-Id: <bp6hl5$nti$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Ben Morrow
<usenet@morrow.me.uk>], who wrote in article <bp4m5j$43q$1@wisteria.csv.warwick.ac.uk>:
> > I guess I will need something entirely different then to break out of the
> > eval {} within a thread. Any ideas? :)
>
> You want another thread that sleeps for a while and then kills the first.
Do not forget to find which signal is generated when thread is killed,
and install a handler for this like this:
$SIG{TERM} = sub {die "thread killed"};
Then (on most systems?) the thread termination sequence will run.
Hmm, will it? I suddently realized that maybe this needs a special
logic installed in Perl. And given that *now* perl uses unreliable
signal model by default, AND knowing how shitty the current (so
called) "thread model" of Perl is, I start to doubt that it will work...
Hope this helps,
Ilya
------------------------------
Date: Sat, 15 Nov 2003 17:08:24 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns9434B8A8FCF9Csdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp5cl7$1l1qb6$1@ID-
184292.news.uni-berlin.de:
> Eric J. Roode wrote:
>> I just can't believe that anyone would advocate writing one's own
>> limited CGI parsing code from scratch, against using the robust,
>> flexible CGI.pm off the shelf.
>
> One situation where doing so makes sense is when efficiency matters.
>
> I have a program, where I believe it would be indefensible to have it
> load CGI.pm. Maybe that's why I'm so sensible about this. :)
If I recall correctly, CGI.pm has only about 200 lines of code that gets
compiled when the module is first loaded. If the time it takes to
compile those 200 lines makes a difference in the execution of your
program, then I suspect Perl/CGI is the wrong technology to be using.
:-) I'd suggest mod_perl, FastCGI, or maybe even writing the CGI input
parsing code in C and loading it via XS.
What sort of timing did you use to determine that CGI.pm was slowing you
down? I keep hearing that CGI.pm is slow and inefficient, but I have
never seen any numbers to back it up, and in my (admittedly anecdotal)
experience, I haven't seen a problem with it.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP7ayEmPeouIeTNHoEQJBJwCgr5zedNlpZf1OdzUPrl3kGEmb0+MAoNvP
+M/xpcGcBuUXU0lupBZ1755w
=oAwu
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 16 Nov 2003 00:33:15 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp6dm6$1kg9c9$1@ID-184292.news.uni-berlin.de>
Eric J. Roode wrote:
> Gunnar Hjalmarsson wrote:
>> Eric J. Roode wrote:
>>> I just can't believe that anyone would advocate writing one's
>>> own limited CGI parsing code from scratch, against using the
>>> robust, flexible CGI.pm off the shelf.
>>
>> One situation where doing so makes sense is when efficiency
>> matters.
>>
>> I have a program, where I believe it would be indefensible to
>> have it load CGI.pm.
>
> If I recall correctly, CGI.pm has only about 200 lines of code that
> gets compiled when the module is first loaded. If the time it
> takes to compile those 200 lines makes a difference in the
> execution of your program, then I suspect Perl/CGI is the wrong
> technology to be using. :-) I'd suggest mod_perl, FastCGI, or
> maybe even writing the CGI input parsing code in C and loading it
> via XS.
Please see my reply to Alan about that.
> What sort of timing did you use to determine that CGI.pm was
> slowing you down?
None.
It's just that the program by its very nature may be used in such a
way that repeated calls put quite some load on the server. For that
reason I'm trying to avoid unnecessary load, and since I have already
"reinvented the wheel", keeping to not using CGI.pm is an easy
contribution to that goal.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 15 Nov 2003 18:07:53 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: arrange form data in same order as on form
Message-Id: <Xns9434C2BE3395Dsdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:bp6dm6$1kg9c9$1@ID-
184292.news.uni-berlin.de:
>> What sort of timing did you use to determine that CGI.pm was
>> slowing you down?
>
> None.
>
> It's just that the program by its very nature may be used in such a
> way that repeated calls put quite some load on the server. For that
> reason I'm trying to avoid unnecessary load, and since I have already
> "reinvented the wheel", keeping to not using CGI.pm is an easy
> contribution to that goal.
Wait, let me get this straight -- you have no idea whether CGI.pm is faster
or slower than your own code, yet you choose to stick to your own code in
the belief that it contributes to your goal of avoiding unnecessary load?
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP7bAAmPeouIeTNHoEQLMKQCaApd4QCCvLJVFyXPuLm/beJRuSJAAoLzo
0dKs9LXp4Ld7eY0KGVncX2+K
=LKAc
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 16 Nov 2003 01:22:15 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: arrange form data in same order as on form
Message-Id: <bp6gi8$1kvq68$1@ID-184292.news.uni-berlin.de>
Eric J. Roode wrote:
> Gunnar Hjalmarsson wrote:
>> Eric J. Roode wrote:
>>> What sort of timing did you use to determine that CGI.pm was
>>> slowing you down?
>>
>> None.
>>
>> It's just that the program by its very nature may be used in such
>> a way that repeated calls put quite some load on the server. For
>> that reason I'm trying to avoid unnecessary load, and since I
>> have already "reinvented the wheel", keeping to not using CGI.pm
>> is an easy contribution to that goal.
>
> Wait, let me get this straight -- you have no idea whether CGI.pm
> is faster or slower than your own code, yet you choose to stick to
> your own code in the belief that it contributes to your goal of
> avoiding unnecessary load?
Yes, I have an idea. I'm sure that CGI.pm is slower. Thought the code
I posted made that apparent to anybody who has an idea of what CGI.pm
is about.
However, I can't tell *how much* slower since I haven't measured it.
Why are you making such a fuss about that?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 15 Nov 2003 16:56:57 -0800
From: jl_post@hotmail.com (J. Romano)
Subject: Re: binmode and the diamond operator
Message-Id: <b893f5d4.0311151656.4b8195ec@posting.google.com>
> > > > So I need to set binmode() on these files, but how do I do it with
> > > > the diamond operator?
> > >
> > > binmode ARGV;
> >
> > Thanks for the response, Tad, but it doesn't work. At least, I
> > haven't figured out where to put the that line to make it work
> > correctly. Should I put it before the "while (<>)" loop or inside it?
>
> A nice conundrum!
>
> I can't find any way to make it work with 5.6... if you're using that
> I think you'll have to write the loop 'properly' (ie. not use <> and
> ARGV, but open and then binmode each file yourself), which pretty much
> rules out one-liners.
I tried to find a solution to this problem, and I found a little
work around. For those of you who don't remember, I was trying get
the following code to use the diamond operator in binmode (on Win32
platforms) so my \r\n or \n\r combinations wouldn't get converted to
one character:
#!/usr/bin/perl -w
use strict;
$/ = undef; # set "slurp" mode
while (<>) {
my $fileLen = -s $ARGV;
my $numChars = length $_;
print "File \"$ARGV\" contains $fileLen bytes",
" and $numChars characters.\n";
}
__END__
This code, when run on Win32 platforms with text file names as
parameters, reports that there are more bytes to the file than
characters. It says this because it considers the \r\n and \n\r
combinations (that occur at newlines) as one character.
My problem is that I wanted to stop this behavior by calling
binmode on the filehandle, so that the number of characters reported
would be the same as the number of bytes. But the diamond operator
doesn't use a filehandle! So how do you tell the diamond operator to
open files in binmode?
The obvious answer, "binmode(ARGV);", didn't work. If called
before the while loop containing the diamond operator, a warning would
appear stating that binmode is being called on an unopened filehandle.
And calling it as the first line of the while loop is too late, since
the line has already been read (in ascii mode) into $_.
The only solution I could think of at the time was to write out the
program the long way, looping through @ARGV and and opening the files
(and setting them with binmode) individually. But, as Ben morrow
said, this pretty much rules out one-liners.
Well, like I said above, I found a little work around. Instead of
adding the line:
binmode(ARGV);
I add the following line as the first line of my while loop:
binmode(ARGV), seek(ARGV,0,0), next if $a = !$a;
so the above script now looks like:
#!/usr/bin/perl -w
use strict;
$/ = undef; # set "slurp" mode
while (<>) {
binmode(ARGV), seek(ARGV,0,0), next if $a = !$a;
my $fileLen = -s $ARGV;
my $numChars = length $_;
print "File \"$ARGV\" contains $fileLen bytes",
" and $numChars characters.\n";
}
__END__
Do you see what it's doing? When it reads a file in for the first
time, it sets the filehandle to binary mode, then rewinds the file
pointer and repeats the loop. The if condition (if $a = !$a) forces
this statement to get executed only on every other loop (otherwise it
would be an infinite loop).
This solution definitely works, but it's obvious that it's not
super-efficient since every file is read twice. If I really wanted to
make it more efficient, I could set $/ to equal a reference to 1 (so
only one byte is read), then set binmode, rewind the pointer, AND set
$/ to undef before restarting the loop. That way only the first byte
would be re-read. Of course, I would have to reset $/ to a reference
to 1 at the end of the loop before the next file is read.
(Some people might point out that I could set $/ to a reference to
0 so I wouldn't have to re-read any bytes at all. Well, I already
tried this and it seems like doing so causes the diamond operator to
read in the entire pseudo-file all at once (in other words, instead of
reading one file at a time, it reads all the files at once and puts
all their contents into $_ as one long string). I tried to find some
documentation that covered this, but I couldn't find any. I'm curious
to know if this is normal behavior.)
But if I use this more efficient solution of only re-reading one
byte, then it's almost more trouble than it's worth, and difficult to
remember for one-liners. So I'll probably stick to the solution:
binmode(ARGV), seek(ARGV,0,0), next if $a = !$a;
for one liners if I'm too lazy to open the files individually.
It's kind of a strange solution, isn't it? At least it works.
-- Jean-Luc
------------------------------
Date: Sat, 15 Nov 2003 23:18:50 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: Chomp doesn't work for me
Message-Id: <3FB6B430.1000802@rochester.rr.com>
Mike Flannigan wrote:
> Here's a script that does what I needed. It sure took me
> a long time to get it going correctly. Please feel free
> to comment on any part of the script, but I'd really like
> to know why:
>
> 1) I could not chomp the new line off the end of the
> 2nd column ($_->[1]) no matter what I did. I tried
> about 8 different things and they either turned the
> string into a "1", a"0", or nothing at all. What's the proper
> (simple) way to do it?
Maybe it's because your program doesn't contain a call to chomp? The
simple way would be:
my @data=<DATA>;
chomp @data;
@data = map [ split /\t/, $_, 2 ], @data;
That way you don't have to fuss around trying to chomp something in a
list of lists -- you can just use a simple array chomp.
>
> 2) Why didn't my substring work on line 13?
That's probably because you messed up on operator precedence. Note that
(substr $_->[0],1 eq "#")
is the same as:
(substr($_->[0],(1 eq "#")))
In this case, you want to use the parens. Note that the comma has a
particularly low operator precedence -- much lower than eq.
My other comments are: It doesn't look like it is really necessary to
read the entire file into an array. If you had a humongo input file, it
would be much better to read it line-by-line. Since you process @data
only once (not counting the map transformation which could easily be
done line-by-line without the complication of map) and line-by-line, it
would have required no significant modification to your program to do it
line-by-line.
...
> Mike
>
>
>
> use strict;
> use warnings;
>
> my %nam;
> my $nam;
> my $namt = "";
> my $lc;
>
> my @data = map [ split /\t/, $_, 2 ], <DATA>;
>
> foreach (@data) {
> if (($_->[0] eq "#") and ($_->[1] eq "#\n")) {
> # if ((substr $_->[0],1 eq "#") and
(substr $_->[1],1 eq "#")) { #LINE 13
> $nam{$namt}++;
> # $loc{$loct}++;
> $namt = "";
> next;
> }
> else {
> $namt .= " $_->[0].$_->[1]";
I doubt the above is actually doing what you want?? You want to
concatenate $namt with a string consisting of a space, whatever is in
$_->[0], a period, and whatever is in $_->[1]?
> # $loct .= " $_->[1]";
> }
> }
>
> for (keys %nam) {
> print "$_\t$nam{$_}\n";
> }
>
> __DATA__
...
[Note: tabs in your data were not preserved during posting, so I
guessed at where they went. For posting purposes, please use something
else for a delimiter -- thanks.]
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Sun, 16 Nov 2003 00:17:03 GMT
From: tiltonj@erols.com (Jay Tilton)
Subject: Re: Chomp doesn't work for me
Message-Id: <3fb6bfe6.123480155@news.erols.com>
Mike Flannigan <mikeflan@earthlink.net> wrote:
: 1) I could not chomp the new line off the end of the
: 2nd column ($_->[1]) no matter what I did. I tried
: about 8 different things and they either turned the
: string into a "1", a"0", or nothing at all. What's the proper
: (simple) way to do it?
The "1" or "0" suggests you were using the value returned by chomp().
I'll make a guess that you were doing it like
$foo = chomp($foo);
That's not the way to do it. chomp() alters its argument in-place,
rather than returning the altered string.
chomp($foo);
If my guess is incorrect, show some of the eight different ways you
tried to use chomp().
------------------------------
Date: Sat, 15 Nov 2003 18:17:33 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Chomp doesn't work for me
Message-Id: <Xns9434C4623F572sdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
Mike Flannigan <mikeflan@earthlink.net> wrote in
news:3FB6ABB9.31EE082C@earthlink.net:
> Here's a script that does what I needed. It sure took me
> a long time to get it going correctly. Please feel free
> to comment on any part of the script, but I'd really like
> to know why:
>
> 1) I could not chomp the new line off the end of the
> 2nd column ($_->[1]) no matter what I did. I tried
> about 8 different things and they either turned the
> string into a "1", a"0", or nothing at all. What's the proper
> (simple) way to do it?
I don't see any incorrect usage of chomp in your program. In fact, I
don't see any usage of chomp at all.
Perhaps you were expecting people to guess at how you were using chomp?
Very well, I *guess* that you were doing:
$foo = chomp $foo;
when you should have simply done:
chomp $foo;
Did you look at the documentation for the chomp function?
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP7bCSGPeouIeTNHoEQLQGgCdFLl5Nv19w3ErpkKarLLOR770UBAAoNZh
hBRwyJERruz3r8XcKWRVbuDP
=WzDD
-----END PGP SIGNATURE-----
------------------------------
Date: Sun, 16 Nov 2003 01:48:18 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Chomp doesn't work for me
Message-Id: <3FB6D81A.66C5464@earthlink.net>
Jay Tilton wrote:
> The "1" or "0" suggests you were using the value returned by chomp().
> I'll make a guess that you were doing it like
>
> $foo = chomp($foo);
>
> That's not the way to do it. chomp() alters its argument in-place,
> rather than returning the altered string.
>
> chomp($foo);
>
> If my guess is incorrect, show some of the eight different ways you
> tried to use chomp().
Crap, wouldn't you know it - I accidentally deleted all those earlier
versions of this file. But I did mostly do it the way you say I
should have. I'll recreate some of them here:
Some of them were like:
$le = $_->[1];
chomp $le;
Some of the really dumb ones were:
chomp $nam{$namt}++;
foreach chomp (@data) {
$nam{chomp $namt}++;
There really were about 8, but I can't recall them all.
------------------------------
Date: Sun, 16 Nov 2003 01:52:26 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Chomp doesn't work for me
Message-Id: <3FB6D912.DF8693C9@earthlink.net>
"Eric J. Roode" wrote:
> I don't see any incorrect usage of chomp in your program. In fact, I
> don't see any usage of chomp at all.
>
> Perhaps you were expecting people to guess at how you were using chomp?
> Very well, I *guess* that you were doing:
>
> $foo = chomp $foo;
>
> when you should have simply done:
>
> chomp $foo;
>
> Did you look at the documentation for the chomp function?
Yes, I did read the documentation on chomp. And I've used it
successfully before. I'm really surprised it didn't work as expected.
I had some of those chomp commands commented out in earlier
versions, but can't put my hands on it right now. Still trying.
------------------------------
Date: 15 Nov 2003 16:58:41 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: extracting Javascript from a web page
Message-Id: <3fb6cbc1@news.victoria.tc.ca>
Alex (aturchin@iname.com) wrote:
: Hi Everyone,
: I have a perl script which tries to read a web page and then submit
: data to a form using LWP::UserAgent. The page has some Javascript in
: the header which does not show when I look at the page's source, and
: which - I suspect - is crucial to filling the form out correctly (I
: keep getting 500 Server Error otherwise).
: I am trying to find out if there is a way to see that "hidden"
: Javascript
How does one "hide" javascript?
Me thinks that it must be visible somewhere.
Either there is a link ( src=... ) or there are frames or multiple windows
and the javascript is visible (or linked) in that other frame or window.
BTW: someone mentioned a javascript module. It might be fun to use that
module to run the javascript to help fill in the form.
------------------------------
Date: Sat, 15 Nov 2003 18:20:26 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: regex to convert 1000000 -> 1,000,000 ?
Message-Id: <Xns9434C4DEDB46Fsdn.comcast@216.196.97.136>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"Wally Sanford" <wsanford@wallysanford.com> wrote in news:bp5uc3$1jpjek$1
@ID-196529.news.uni-berlin.de:
> And as usual, you miss the point that most new people would not have
> _knowlege_ of na faq. It's like when ou go to a new place. Say, you move
> to a new state, go to a new school, you know not wher anything really
> is, you tend to ask around "hey, do you know where I can find this or
> that?". You _can't_ expect every new person to know where to find
> everything, becuase they may not even know of the exisitance of such a
> tool.
On the other hand, usenet is an established community with an established
culture, and ignoring the culture of the place you're visiting is most
definitely rude.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP7bC9WPeouIeTNHoEQIg4QCg6kFeBr+oLvD72aWGEcp6eDBWRLQAoKIA
Prkt90Zc7z603nNX81ZWCfCn
=3zoC
-----END PGP SIGNATURE-----
------------------------------
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.
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 5810
***************************************
