[23665] in Perl-Users-Digest
Perl-Users Digest, Issue: 5872 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Nov 29 14:05:57 2003
Date: Sat, 29 Nov 2003 11:05:10 -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, 29 Nov 2003 Volume: 10 Number: 5872
Today's topics:
Array Indexing problem (Harish)
Re: Array Indexing problem <hexkid@hotpop.com>
Re: DBI error handling (Malcolm Dew-Jones)
Re: DBI error handling <tore@aursand.no>
Re: DBI error handling <jwillmore@remove.adelphia.net>
Re: DBI error handling <tassilo.parseval@rwth-aachen.de>
Re: DBI error handling <usenet@morrow.me.uk>
Re: DBI error handling <r_reidy@comcast.net>
Re: DBI error handling <tore@aursand.no>
Re: DBI error handling <tore@aursand.no>
Re: DBI error handling (Randal L. Schwartz)
Ignore quoted text in reg exp (nick)
Re: Ignore quoted text in reg exp <bigus_34@yahoo.co.uk>
Re: Ignore quoted text in reg exp (nick)
My auction: Multiple people accessing the same text dat <someone@microsoft.com>
Re: My auction: Multiple people accessing the same text (William Herrera)
Re: Newsgroup Searching Program <jwillmore@remove.adelphia.net>
Re: Packages and returning errors <bigus_34@yahoo.co.uk>
Re: Packages and returning errors <usenet@morrow.me.uk>
Re: Perl unicode and :crlf, was Re: regexp: \x0a => \x0 <usenet@morrow.me.uk>
Re: Problem while installing through PPM. <randy@theoryx5.uwinnipeg.ca>
Re: problem (William Herrera)
Reading Dates from Excel-file (bruno)
Re: Reading Dates from Excel-file <invalid-email@rochester.rr.com>
Re: Seeking Perl / Linux tutor <tom@nosleep.net>
traping a request termination from a browser <johnm@aiamail.com>
Re: traping a request termination from a browser <usenet@morrow.me.uk>
Re: Using perl -e to remove times/dates from a file <bik.mido@tiscalinet.it>
Re: Will trade money for quick help <dha@panix.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 29 Nov 2003 10:18:20 -0800
From: harish_recian@yahoo.com (Harish)
Subject: Array Indexing problem
Message-Id: <a3ef9093.0311291018.23bf6d03@posting.google.com>
Hi,
I am having a problem while indexing an element in perl.
Problem Details:
I have a data file which looks like the below
0.5 2 0.01 0 92 44 19818
0.5 2 0.015 0 62 42 19869
0.5 2 0.02 0 49 37 19902
0.5 2 0.025 0 40 30 19920
0.5 2 0.03 0 32 27 19935
0.5 2 0.035 0 28 31 19942
0.5 2 0.04 0 23 24 19952
I need to selectively take few lines from this file store it into
another file.
I'm doing this by storing the file into an array. Then i would
generate the index where the line that i'm interested in is located
and then access the line and store in another file.My program seems to
be working fine for everything except for few lines.
if i have $x=4 then when i say $temp[$x] it prints the previous line
but when i say $temp[4] it prints the line that i'm interested in.
This does not happen for all the lines.It is just happening for few
lines.
Could u let me know where I'm going wrong here.
Thanks
Harish
P.S.
I'm attaching the code below. Here $x is used to generate the index
number.There is nothing wrong in the logic of genrating $x.
if (!open(INFILE,"<f1.dat"))
{
die("cannot open file data.dat\n");
}
@temp = <INFILE>;
close(INFILE);
if (!open(OUTFILE,">testdata1.dat"))
{
die("cannot open file validation$a.dat\n");
}
@aspect = (0.5);
@delay=(0.01,0.02,0.03);
@msizes = (2);
foreach $line1 (@aspect)
{
$p =($line1-0.5)*20;
foreach $line2 (@msizes)
{
$q = ($line2-2);
foreach $line3 (@delay)
{
$r = (($line3-0.01)*200);
$x = $p*836+$q*19+$r;
print OUTFILE "$temp[$x]\n";
}
}
}
------------------------------
Date: 29 Nov 2003 18:26:57 GMT
From: Pedro Graca <hexkid@hotpop.com>
Subject: Re: Array Indexing problem
Message-Id: <bqaodh$20mv7n$1@ID-203069.news.uni-berlin.de>
Harish wrote:
[snip]
> $r = (($line3-0.01)*200);
> $x = $p*836+$q*19+$r;
> print OUTFILE "$temp[$x]\n";
are you sure $x is an integer? print it!
$ perl -e '$x=1.99998; @t=(1, 2, 3, 4); print $x, " ==> ", $t[$x], "\n";'
prints
1.99998 ==> 2 [as if $x was 1]
--
--= my mail box only accepts =--
--= Content-Type: text/plain =--
--= Size below 10001 bytes =--
------------------------------
Date: 28 Nov 2003 20:33:23 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: DBI error handling
Message-Id: <3fc82193@news.victoria.tc.ca>
Tore Aursand (tore@aursand.no) wrote:
: On Thu, 27 Nov 2003 08:39:09 -0700, Ron Reidy wrote:
: >>> I've a perl script which inserts data to a database. Sometime I get an
: >>> error on the execute() statement. Now I want the script not to die but
: >>> to exit the loop and to try again with the next record.
: >> [...]
: >> See 'perldoc DBI' for more information.
: > And perldoc -f eval
: Why?
eval is used to trap `die'.
------------------------------
Date: Sat, 29 Nov 2003 08:44:04 +0100
From: Tore Aursand <tore@aursand.no>
Subject: Re: DBI error handling
Message-Id: <pan.2003.11.29.06.16.56.339823@aursand.no>
On Fri, 28 Nov 2003 20:33:23 -0800, Malcolm Dew-Jones wrote:
>>>> [...]
>>>> See 'perldoc DBI' for more information.
>>> And perldoc -f eval
>> Why?
> eval is used to trap `die'.
Why would you want to do that? There is no need to trap 'die' in this
case.
And - I really don't think 'eval' should be used primarily to trap 'die',
but that's my opinion of course.
--
Tore Aursand <tore@aursand.no>
"To cease smoking is the easiset thing I ever did. I ought to know,
I've done it a thousand times." -- Mark Twain
------------------------------
Date: Sat, 29 Nov 2003 09:02:38 GMT
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: DBI error handling
Message-Id: <20031129040237.4c9ccb55.jwillmore@remove.adelphia.net>
On Fri, 28 Nov 2003 18:05:13 -0600
"Eric J. Roode" <REMOVEsdnCAPS@comcast.net> wrote:
> James Willmore <jwillmore@remove.adelphia.net> wrote in
> news:20031128125046.46d457b0.jwillmore@remove.adelphia.net:
>
> > What would be better is the following (untested)
> >
> > my $dbh = DBI->connect("dbi:ODBC:$dsn", $user, $pass,
> > {PrintError=>1,
> > RaiseError=>1}
> > or die "Can't connect: ", $DBI::errstr,"\n";
<snip>
> > $rs = $dbh->prepare($stmt)
> > or die "Can't prepare: ", $dbh->errstr,"\n";
>
> "or die"...? You set RaiseError above. You're not going to get the
> chance to die; prepare() will die for you.
True. I meant to set that to '0'. :-(
> > #now execute the statement foreach value
> > while(my(@row) = $sth->fetchrow_array){
> > $rs->execute(@row)
> > or warn "Insert failed for the following:\n", join("|",@row),"\n",
>
> Ditto here -- you won't get the chance to warn.
True again.
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
Yes, but which self do you want to be?
------------------------------
Date: 29 Nov 2003 11:30:46 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: DBI error handling
Message-Id: <bqa016$7ou$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Tore Aursand:
> On Fri, 28 Nov 2003 20:33:23 -0800, Malcolm Dew-Jones wrote:
>>>>> [...]
>>>>> See 'perldoc DBI' for more information.
>
>>>> And perldoc -f eval
>
>>> Why?
>
>> eval is used to trap `die'.
>
> Why would you want to do that? There is no need to trap 'die' in this
> case.
>
> And - I really don't think 'eval' should be used primarily to trap 'die',
> but that's my opinion of course.
'eval BLOCK' can only be used for trapping abnormal termination. It's
sort of Perl's equivalent to Java's 'try'. Are you maybe confusing 'eval
BLOCK' with 'eval STRING'?
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sat, 29 Nov 2003 11:39:16 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: DBI error handling
Message-Id: <bqa0h4$qnp$1@wisteria.csv.warwick.ac.uk>
Tore Aursand <tore@aursand.no> wrote:
> And - I really don't think 'eval' should be used primarily to trap 'die',
> but that's my opinion of course.
How else would you do it?
Ben
--
Like all men in Babylon I have been a proconsul; like all, a slave ... During
one lunar year, I have been declared invisible; I shrieked and was not heard,
I stole my bread and was not decapitated.
~ ben@morrow.me.uk ~ Jorge Luis Borges, 'The Babylon Lottery'
------------------------------
Date: Sat, 29 Nov 2003 07:41:03 -0700
From: Ron Reidy <r_reidy@comcast.net>
Subject: Re: DBI error handling
Message-Id: <3FC8AFFF.1060605@comcast.net>
Tore Aursand wrote:
> On Thu, 27 Nov 2003 08:39:09 -0700, Ron Reidy wrote:
>
>>>>I've a perl script which inserts data to a database. Sometime I get an
>>>>error on the execute() statement. Now I want the script not to die but
>>>>to exit the loop and to try again with the next record.
>>>
>
>>>[...]
>>>See 'perldoc DBI' for more information.
>>
>
>>And perldoc -f eval
>
>
> Why?
>
To trap errors and continue processing.
>
--
Ron Reidy
Oracle DBA
------------------------------
Date: Sat, 29 Nov 2003 19:00:43 +0100
From: Tore Aursand <tore@aursand.no>
Subject: Re: DBI error handling
Message-Id: <pan.2003.11.29.17.53.19.537901@aursand.no>
On Sat, 29 Nov 2003 11:39:16 +0000, Ben Morrow wrote:
>> And - I really don't think 'eval' should be used primarily to trap
>> 'die', but that's my opinion of course.
> How else would you do it?
Do what? Trap 'die'? I don't know - I've never been forced to trap
'die', and either way it's off-topic.
The OP asked how to trap DBI errors, and you don't need to trap 'die' to
do that. The DBI module only dies upon errors when the RaiseError flag is
set to a true value (a false value is default).
IMO, it's a bad habit to try to find out if your application, or a module
it's using, dies if there are ways to handle the errors in a better way.
With the DBI module - and most other modules - that's not a problem (as
explained in a previous post from me).
--
Tore Aursand <tore@aursand.no>
"To cease smoking is the easiset thing I ever did. I ought to know,
I've done it a thousand times." -- Mark Twain
------------------------------
Date: Sat, 29 Nov 2003 19:00:43 +0100
From: Tore Aursand <tore@aursand.no>
Subject: Re: DBI error handling
Message-Id: <pan.2003.11.29.17.55.35.51732@aursand.no>
On Sat, 29 Nov 2003 07:41:03 -0700, Ron Reidy wrote:
>>>> [...]
>>>> See 'perldoc DBI' for more information.
>>> And perldoc -f eval
>> Why?
> To trap errors and continue processing.
No need for that in this case. Avoid using 'eval', if possible, is my
suggestion.
--
Tore Aursand <tore@aursand.no>
"To cease smoking is the easiset thing I ever did. I ought to know,
I've done it a thousand times." -- Mark Twain
------------------------------
Date: Sat, 29 Nov 2003 18:27:10 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: DBI error handling
Message-Id: <257927e63d67e3b3509a5673b8fc34aa@news.teranews.com>
>>>>> "Tore" == Tore Aursand <tore@aursand.no> writes:
Tore> IMO, it's a bad habit to try to find out if your application, or a module
Tore> it's using, dies if there are ways to handle the errors in a better way.
Tore> With the DBI module - and most other modules - that's not a problem (as
Tore> explained in a previous post from me).
You're not "thinking Perl" then. I find the RaiseError mechanism
to create much cleaner code. When enabled, I can do things like:
eval {
...;
...;
...;
...;
};
if ($@) {
# something went wrong with something in this section
}
whereas without RaiseError, I'm stuck setting status variables
and nesting if statements to get the same effect.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: 29 Nov 2003 00:24:56 -0800
From: nickgieschen@hotmail.com (nick)
Subject: Ignore quoted text in reg exp
Message-Id: <305cab98.0311290024.747be0bc@posting.google.com>
I can't seem to figure out how to ignore quoted text in a regular
expression. For example, I would like a reg exp to match 1-3, but not
4:
my name is nick
my "string"name"string" is nick
my "text" name "text" is nick
my "name" is nick
Is this even possible?
Thanks for any help.
Nick
------------------------------
Date: Sat, 29 Nov 2003 09:53:48 -0000
From: "Bigus" <bigus_34@yahoo.co.uk>
Subject: Re: Ignore quoted text in reg exp
Message-Id: <M0_xb.1543$Hy3.983@newsfep4-winn.server.ntli.net>
"nick" <nickgieschen@hotmail.com> wrote in message
news:305cab98.0311290024.747be0bc@posting.google.com...
> I can't seem to figure out how to ignore quoted text in a regular
> expression. For example, I would like a reg exp to match 1-3, but not
> 4:
>
> my name is nick
> my "string"name"string" is nick
> my "text" name "text" is nick
> my "name" is nick
Well, you could do something like this:
@str = (
'my name is nick',
'my "string"name"string" is nick',
'my "text" name "text" is nick',
'my "name" is nick'
);
foreach (@str) {
($temp = $_) =~ s/".*?"//g;
if ($temp =~ /my.*name.*is.*nick/i) { print "found in $_\n"; }
};
What that is doing is using a temp variable to hold the contents of $_ (so
as to avoid wrecking your original array), remove anything in quotes and
then search for 'my name is nick'.
Bigus
------------------------------
Date: 29 Nov 2003 10:07:32 -0800
From: nickgieschen@hotmail.com (nick)
Subject: Re: Ignore quoted text in reg exp
Message-Id: <305cab98.0311291007.20905477@posting.google.com>
"Bigus" <bigus_34@yahoo.co.uk> wrote in message news:<M0_xb.1543$Hy3.983@newsfep4-winn.server.ntli.net>...
> "nick" <nickgieschen@hotmail.com> wrote in message
> news:305cab98.0311290024.747be0bc@posting.google.com...
> > I can't seem to figure out how to ignore quoted text in a regular
> > expression. For example, I would like a reg exp to match 1-3, but not
> > 4:
> >
> > my name is nick
> > my "string"name"string" is nick
> > my "text" name "text" is nick
> > my "name" is nick
>
> Well, you could do something like this:
>
> @str = (
> 'my name is nick',
> 'my "string"name"string" is nick',
> 'my "text" name "text" is nick',
> 'my "name" is nick'
> );
>
> foreach (@str) {
> ($temp = $_) =~ s/".*?"//g;
> if ($temp =~ /my.*name.*is.*nick/i) { print "found in $_\n"; }
> };
>
> What that is doing is using a temp variable to hold the contents of $_ (so
> as to avoid wrecking your original array), remove anything in quotes and
> then search for 'my name is nick'.
>
> Bigus
Thanks. Unfortunately it doesn't really work for my purposes. (Well,
it might, but it would end up getting messy.) I need to search in the
original string since I'm doing some replacing. I am hoping there is a
clean way to do this.
What I'm doing is searching for the tag <script runat="server"> and
replacing it with <TAG><script runat="server"></TAG>. However, the
runat="server" cannot be quoted, as in <script 'runat="server"'>.
There can also be other parameters in the runat tag, such as <script
language="jscript" runat="server">. In this case the replacement would
be <TAG><script language="jscript" runat="server"></TAG>. So, I can't
simply strip out the quoted text.
Any ideas?
Thanks.
Nick
------------------------------
Date: Sat, 29 Nov 2003 18:19:10 GMT
From: "John Smith" <someone@microsoft.com>
Subject: My auction: Multiple people accessing the same text data file at the same time... Ouch!
Message-Id: <yq5yb.444$IF6.36390@ursa-nb00s0.nbnet.nb.ca>
I created a program for a local on-line auction used in a charity
fundraiser.
In all, there were approximately 150 items, 700 users (people who
registered), and approximately 2000 bids during the one week that it was
live.
I used a tab-delimited text file for keeping track of bids.
Although the file contains 5 fields: (the item number, bid amount, date of
bid, username of bidder, and the number of bids on the item), let's keep
things simple and assume only 3 fields (the item number, bid amount, and the
username of the bidder).
The file would look something like this:
1 5.25 joe
2 6.15 sue
3 2.50 john
4 3.75 bob
Each field is separated by a tab. The actual file had 150 lines (1 line for
each item).
When someone submitted a bid, the program did 2 things:
a) Read the file and close it
b) Re-write the file with the new information and close it.
It worked great, until the last 10 minutes of the auction when the file got
corrupted. It was fortunate that I also kept a log of every bid so I didn't
lose anything.
What happened of course is that everyone waited until the last minute to
make their bid. There were approximately 500 bids in the last 15 minutes.
At first, I thought that if someone submitted a bid from the website, it
would go to the web server and my perl script would do what it had to and
then terminate. If someone else was bidding at the same time, the server
would have to wait until the perl script had finished the first request, and
then the server would call on the perl script again to do the second
request.
What I have to assume now is that many threads of the perl script could be
running at the same time. What I mean is that although the perl script
hadn't finished its first request, a second thread could be started, etc,
etc,... So basically multiple threads of the perl script could be running
simultaneously, and accessing that text data file at the same time.
I don't know if there's a way to limit the number of threads that the perl
script can run simultaneously (to just one). Or perhaps if it was possible
to set the file properties to disallow multiple access.
So now I'm thinking that perhaps this type of programming (using simple text
files as data files) has many disadvantages compared to using real data
files. Unfortunately, I'm not at that stage of linking Microsoft Data Base
files or whatever data files, I haven't graduated to that level yet.
Does anyone know a simple way to tackle this? Any ideas at all?
Thanks for all
G.Doucet
The following are parts of the routines that read, and re-write the data
file.
# Variables
# $item = number of the item
# $bida = bid amount
# $code = username of bidder
# $bidsfil = 'bids.txt' <--- the actual data file described above
# @bidsfile = content of entire file
# $bidsline = individual line (record) of file
# $bidsfield = individual field of record
if(open(FILE,"$bidsfil")) # Open the file for
reading
{ #
@bidsfile=<FILE>; # Read the entire file
close(FILE); # Close the file
} #
if(open(FILE,">$bidsfil")) # Open the file for
writing
{ #
$i=0; # set counter to zero
foreach $bidsline (@bidsfile) # Loop through every line
in the file
{ #
$i++; # increment counter
if($i==$item) # check if we're at the
correct item
{ #
@bidsfield=(); # push the contents of the
line into fields
push(@bidsfield,split(/\t/,$bidsline)); # get the current bid
$cbid = $bidsfield[1]; #
#
if($bida>$cbid) # if the bid is higher...
{ #
$bidsline="$i\t$bida\t$code\t\n"; # ...re-create the line
with new bid amount
} #
#
} #
print FILE $bidsline; # print line to the file
} #
close(FILE); # Close the file
} #
------------------------------
Date: Sat, 29 Nov 2003 18:43:49 GMT
From: posting.account@lynxview.com (William Herrera)
Subject: Re: My auction: Multiple people accessing the same text data file at the same time... Ouch!
Message-Id: <3fc8e6b2.664883362@news2.news.adelphia.net>
On Sat, 29 Nov 2003 18:19:10 GMT, "John Smith" <someone@microsoft.com> wrote:
>I created a program for a local on-line auction used in a charity
>fundraiser.
>In all, there were approximately 150 items, 700 users (people who
>registered), and approximately 2000 bids during the one week that it was
>live.
>
>I used a tab-delimited text file for keeping track of bids.
>Although the file contains 5 fields: (the item number, bid amount, date of
>bid, username of bidder, and the number of bids on the item), let's keep
>things simple and assume only 3 fields (the item number, bid amount, and the
>username of the bidder).
>
>The file would look something like this:
>1 5.25 joe
>2 6.15 sue
>3 2.50 john
>4 3.75 bob
>Each field is separated by a tab. The actual file had 150 lines (1 line for
>each item).
>
>When someone submitted a bid, the program did 2 things:
>a) Read the file and close it
>b) Re-write the file with the new information and close it.
>
>It worked great, until the last 10 minutes of the auction when the file got
>corrupted. It was fortunate that I also kept a log of every bid so I didn't
>lose anything.
>
You failed to lock the file. You need to use flock() to lock as shared when the
file(s) are read and as exclusive when the files are written. This means that
500 people trying to bid at the same time will not happen--last second bidders
will not have their bids made, most likely.
Large bidding sites actually use a timed transaction model--they get
submissions which are forwarded to the engine that updates the bidding file, so
that only one program actually updates the files on disk.
>What happened of course is that everyone waited until the last minute to
>make their bid. There were approximately 500 bids in the last 15 minutes.
>
>At first, I thought that if someone submitted a bid from the website, it
>would go to the web server and my perl script would do what it had to and
>then terminate. If someone else was bidding at the same time, the server
>would have to wait until the perl script had finished the first request, and
>then the server would call on the perl script again to do the second
>request.
>
>What I have to assume now is that many threads of the perl script could be
>running at the same time. What I mean is that although the perl script
>hadn't finished its first request, a second thread could be started, etc,
>etc,... So basically multiple threads of the perl script could be running
>simultaneously, and accessing that text data file at the same time.
>
>I don't know if there's a way to limit the number of threads that the perl
>script can run simultaneously (to just one). Or perhaps if it was possible
>to set the file properties to disallow multiple access.
>
>So now I'm thinking that perhaps this type of programming (using simple text
>files as data files) has many disadvantages compared to using real data
>files. Unfortunately, I'm not at that stage of linking Microsoft Data Base
>files or whatever data files, I haven't graduated to that level yet.
This is not a file type problem. It is a file locking problem. Direct database
file updates would have at least as many problems as text files here. A
separate transaction database server program is likely what would work best.
Of course, since you probably want to encourage people to bid earlier, maybe
you should just use text files and flock()? Of course, some higher bidders at
the end would be locked out. Another method is to announce in advance that the
bidding will go, say, one minute with no higher bids before the bidding closes,
and program the end of bidding time accordingly.
---
Use the domain skylightview (dot) com for the reply address instead.
------------------------------
Date: Sat, 29 Nov 2003 09:33:59 GMT
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: Newsgroup Searching Program
Message-Id: <20031129043358.2e5c9307.jwillmore@remove.adelphia.net>
On Fri, 28 Nov 2003 22:04:10 GMT
Mike Flannigan <mikeflan@earthlink.net> wrote:
>
> James Willmore wrote:
> > And ... use Google :-)
> >
> > There is a *long* thread from about 2 months ago on this very
> > subject:-)
>
> That long thread wasn't on this comp.lang.perl.misc group,
> was it? So far I haven't been able to find it on Google.
> Still looking.
Go to Google and use the following keywords to search for the thread:
"comp.lang.perl.misc View NG with Net::NNTP"
Thread is dated 2 Sept 2003.
HTH
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
"I'd love to go out with you, but I'm taking punk totem pole
carving."
------------------------------
Date: Sat, 29 Nov 2003 10:06:20 -0000
From: "Bigus" <bigus_34@yahoo.co.uk>
Subject: Re: Packages and returning errors
Message-Id: <wc_xb.1465$PR.11479@newsfep4-glfd.server.ntli.net>
"Ben Morrow" <usenet@morrow.me.uk> wrote in message
news:bq81sv$e9r$1@wisteria.csv.warwick.ac.uk...
>
> "Bigus" <someone@somewhere.com> wrote:
> > Yes, I see. I've changed the structure a bit so that it doesn't need a
> > global var, so the package now looks like this:
> >
> > ===================
> > package GD::MyMod;
> >
> > use strict;
> > use warnings;
> > use GD;
> >
> > sub new {
> > my $class = shift;
> > my ($width, $height ) = @_;
> > if ( $width < 100 or $height < 100 ) {
> > rtnError("Specify values >= 100");
> > }
> > else {
> > # do stuff
> > }
> > }
> >
> > sub rtnError {
> > my $class = shift;
> > my $error_msg = shift;
> > return $error_msg;
> > }
>
> This is completely pointless. You are not saving the value of
> $error_msg anywhere.
I got my logic wrong then.. I didn't think I'd need to save the error
outside of the subs because I was passing the error to rtnError with the
line:
rtnError("Specify values >= 100");
and then rtnError was sending it back to the calling program with the line:
return $error_msg;
> You probably meant something like this:
>
> {
> my $last_error;
>
> sub rtnError {
> my $class = shift;
> my $error_msg = shift;
> $error_msg and $last_error = $error_msg;
> return $last_error;
> }
> }
>
> which will return the last thing it was called with if it is called
> with no args.
>
> > So, how would one actualy define $im as the class instance object
thingy? Is
> > that where this bless command comes in?
>
> Yes. Understanding bless is critical to writing OO Perl. Read perlboot
> until you understand it (you will *need* to understand perlsub,
> perlref and perlmod first).
OK thanks.
Bigus
------------------------------
Date: Sat, 29 Nov 2003 11:44:56 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Packages and returning errors
Message-Id: <bqa0ro$qnp$2@wisteria.csv.warwick.ac.uk>
"Bigus" <bigus_34@yahoo.co.uk> wrote:
> > > sub rtnError {
> > > my $class = shift;
> > > my $error_msg = shift;
> > > return $error_msg;
> > > }
> >
> > This is completely pointless. You are not saving the value of
> > $error_msg anywhere.
>
> I got my logic wrong then.. I didn't think I'd need to save the error
> outside of the subs because I was passing the error to rtnError with the
> line:
>
> rtnError("Specify values >= 100");
>
>
> and then rtnError was sending it back to the calling program with the line:
>
> return $error_msg;
... so if you write '$err = $obj->rtnError("Hello world");' you will
get $err = "Hello world"; and if you then write '$err =
$obj->rtnError();' you will get $err = undef. The sub isn't doing
anything.
> > You probably meant something like this:
> >
> > {
> > my $last_error;
> >
> > sub rtnError {
> > my $class = shift;
> > my $error_msg = shift;
> > $error_msg and $last_error = $error_msg;
> > return $last_error;
> > }
> > }
> >
> > which will return the last thing it was called with if it is called
> > with no args.
... i.e. if you write '$obj->rtnError("Hello world"); ...
$err = $obj->rtnError();' then you will have $err = "Hello world",
which is I suspect what you want.
Ben
--
perl -e'print map {/.(.)/s} sort unpack "a2"x26, pack "N"x13,
qw/1632265075 1651865445 1685354798 1696626283 1752131169 1769237618
1801808488 1830841936 1886550130 1914728293 1936225377 1969451372
2047502190/' # ben@morrow.me.uk
------------------------------
Date: Sat, 29 Nov 2003 14:25:53 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Perl unicode and :crlf, was Re: regexp: \x0a => \x0d\x0a
Message-Id: <bqaa9h$574$1@wisteria.csv.warwick.ac.uk>
"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote:
> Incidentally I've found that for utf-8 data the "od -t x1" format is
> handy, rather than "od -x".
Yes, I found that too. -x is good for little-endian stuff, though.
> > I would seriously consider not using :crlf at all, but instead writing
> > a :nl layer that maps any of \n, \r, \r\n to \n on input and any of
> > \n, \r, \r\n to \r\n on output... seems to me that'd be more use, in
> > general. I guess it would probably be slower.
http://morrow.me.uk/PerlIO-nline-0.01.tar.gz
> If it was part of the infrastructure, I doubt that the difference in
> speed would be noticeable.
#!/usr/bin/perl
use Benchmark qw/cmpthese/;
use Fcntl qw/:seek/;
my $teststr = "a\cJb\cMc\cM\cJ";
$/ = undef;
print "Writing mixed:\n";
{
open my $CRLF, ">:crlf", "one";
open my $NLINE, ">:nline", "two";
select((select($CRLF ),$|=1)[0]);
select((select($NLINE),$|=1)[0]);
cmpthese -5, { crlf => sub { print $CRLF $teststr },
nline => sub { print $NLINE $teststr }
};
}
print "Writing just \\n:\n";
{
open my $CRLF, ">:crlf", "one";
open my $NLINE, ">:nline", "two";
select((select($CRLF ),$|=1)[0]);
select((select($NLINE),$|=1)[0]);
cmpthese -5, { crlf => sub { print $CRLF "a\n" },
nline => sub { print $NLINE "a\n" }
};
}
{
open my $RAW, ">:raw", "three";
print $RAW $teststr;
}
print "Reading:\n";
{
open my $CRLF, "<:crlf", "three";
open my $NLINE, "<:nline", "three";
cmpthese -5, { crlf => sub { <$CRLF>; seek $CRLF, 0, SEEK_SET },
nline => sub { <$NLINE>; seek $NLINE, 0, SEEK_SET }
};
}
__END__
Writing mixed:
Rate nline crlf
nline 190612/s -- -23%
crlf 247892/s 30% --
Writing just \n:
Rate nline crlf
nline 229302/s -- -9%
crlf 252560/s 10% --
Reading:
Rate crlf nline
crlf 58405/s -- -0%
nline 58519/s 0% --
Hmmm... not that bad, I suppose, 'specially if you don't use the extra
flexibility.
> Whenever this topic comes up, there's usually someone who offers
> anomalous data and asks what we'd do with it (mixed unix/mac/dos
> newlines...), but that's just as much a problem for :crlf as it would
> be for your hypothetical :nl, so I don't see it as a show-stopper.
I'm /pretty/ sure this layer does the Right Thing in all situations.
Ben
--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] * ben@morrow.me.uk
------------------------------
Date: Sat, 29 Nov 2003 06:26:57 -0600
From: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>
Subject: Re: Problem while installing through PPM.
Message-Id: <mg0yb.29934$MW5.43457@news1.mts.net>
"SK" <sk_ind12@rediffmail.com> wrote in message
news:83dee709.0311271954.c3ae923@posting.google.com...
> Hello,
>
> I am facing a problem while installing DateTime module through PPM.
> when i do a
> ppm> search DateTime
>
> i get the following result
>
> 1. Bundle-DateTime [0.11] Bundle with all DateTime related modules
> 2. DateTime [0.1701] DateTime base objects
> 3. DateTime-Calendar-C~ [0.02] Coptic Calendar System.
> .................
> Which indiactes it can find DateTime module. But now when i try to
install
> using
>
> ppm> install DateTime
>
> I get a message
> Error: no suitable installation target found for package DateTime.
Generally this means that, while it found a DateTime package, it
wasn't for your Perl build (ActiveState maintains a number
ppm packages for different OSs). A look at
http://ppm.activestate.com/BuildStatus/5.6-D.html
indicates that building this particular package failed on Windows.
best regards,
randy kobes
------------------------------
Date: Sat, 29 Nov 2003 05:50:11 GMT
From: posting.account@lynxview.com (William Herrera)
Subject: Re: problem
Message-Id: <3fc83348.618945714@news2.news.adelphia.net>
On 27 Nov 2003 20:48:32 -0800, truman@rediffmail.com (aditya) wrote:
>Hi,
>I am new to perl and I belive the following code has a problem. Can
>someone tell me what? The stuff I want to add in the html page (inside
>the 'if' condition below), it doesnt come at all!
>
>Please help!
>
>Aditya
>
>
>##############################################################################
>package App::Dialog::Field::Scheduling::ReoccuringAppts;
>##############################################################################
>
>use strict;
>use base qw{CGI::Dialog::ContentItem};
>use CGI::Dialog;
>use CGI::Validator::Field;
>use base qw{CGI::Dialog::MultiField};
>
We'd help you, but...where is the source to these modules available? I do not
see them on CPAN.
---
Use the domain skylightview (dot) com for the reply address instead.
------------------------------
Date: 29 Nov 2003 03:30:30 -0800
From: bskorepa@yahoo.com (bruno)
Subject: Reading Dates from Excel-file
Message-Id: <f542e1ac.0311290330.5be1e632@posting.google.com>
I have a script that reads an excel file.
Since I upgraded to activeperl 5.8 the date-fields are read as:
Win32::OLE::Variant=SCALAR(0x20d341c)
before I got real date-values (although I do not remember what
perl-version I had before).
Platform: win2000
thanks for any hints,
Bruno
------------------------------
Date: Sat, 29 Nov 2003 16:12:23 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: Reading Dates from Excel-file
Message-Id: <3FC8C39E.2020100@rochester.rr.com>
bruno wrote:
> I have a script that reads an excel file.
> Since I upgraded to activeperl 5.8 the date-fields are read as:
>
> Win32::OLE::Variant=SCALAR(0x20d341c)
>
> before I got real date-values (although I do not remember what
> perl-version I had before).
> Platform: win2000
...
Please boil your problem down to the shortest possible complete sample
code segment that illustrates your problem, set it up so anyone can
copy/paste/execute it, and post that. We can't comment on code we can't
see and run. Also include your Excel version.
In addition, I'm a bit confused: you say you are reading an Excel file;
but it appears that you are using Win32::OLE, which interfaces with a
running instance of Excel, and does not read an Excel file. Which is it?
> Bruno
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Fri, 28 Nov 2003 20:24:02 -0800
From: "Tom" <tom@nosleep.net>
Subject: Re: Seeking Perl / Linux tutor
Message-Id: <3fc82c91$1@nntp0.pdx.net>
> >
> >The Yahoo IM requirement is an important one since I would like to be
> >able to obtain advice instantly when I need it. Ideally, you already
> >have a habit of usually being online with Yahoo IM.
> >
> >If interested, please contact me at www.7xyz.com/perl
> >
> >Please provide professional references if possible.
> >
> >Thank you.
Try the Oreilly books and your internet search engine instead.
Cheaper and you'll save money and learn more.
>
------------------------------
Date: Sat, 29 Nov 2003 04:23:32 -0600
From: "John Michael" <johnm@aiamail.com>
Subject: traping a request termination from a browser
Message-Id: <vsgst3it98tm74@corp.supernews.com>
Say I were to write a script that would server a large file through a web
interface and record somewhere the file size.
Is it possible for me to know if the user downloading the file terminated
the connection early so that I could record the correct size?
How would I trap this situation so that I could do some sort of roll back or
clean up if this were to happen?
Thanks
JM
------------------------------
Date: Sat, 29 Nov 2003 11:51:33 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: traping a request termination from a browser
Message-Id: <bqa185$qnp$3@wisteria.csv.warwick.ac.uk>
"John Michael" <johnm@aiamail.com> wrote:
> Say I were to write a script that would server a large file through a web
> interface and record somewhere the file size.
>
> Is it possible for me to know if the user downloading the file terminated
> the connection early so that I could record the correct size?
>
> How would I trap this situation so that I could do some sort of roll back or
> clean up if this were to happen?
Depending on your setup, when the user closes the socket your process
may receive SIGPIPE and writes may stop working. You can trap this
condition either with a handler for SIGPIPE or by using syswrite and
checking the return value.
Note that if there are any proxies between the user and you this will
fail (the proxy will probably download the whole file each time); also
that your web server may or may not buffer data: I've no idea. Also
note that web standards dictate that any request which is not
idempotent (i.e. which makes a permanent change server-side) be a POST
rather than a GET.
Ben
--
EAT
KIDS (...er, whoops...)
FOR ben@morrow.me.uk
99p
------------------------------
Date: Sat, 29 Nov 2003 15:08:02 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Using perl -e to remove times/dates from a file
Message-Id: <4dnfsvcf0ccmtct5sqq8pk1nd9j801km7l@4ax.com>
On Fri, 28 Nov 2003 08:30:57 -0600, "Eric J. Roode"
<REMOVEsdnCAPS@comcast.net> wrote:
>On my windows 2000 computer, "dir /b" gives me just a bare list of
>filenames. I don't know if this option is available on all versions of
>dos/windows, but if it is, it'll be easier for you to change your input
>than to post-process it with Perl.
It exists at least since MS-DOS 5.0, that is the first version I
"worked" with.
Michele
--
# This prints: Just another Perl hacker,
seek DATA,15,0 and print q... <DATA>;
__END__
------------------------------
Date: Sat, 29 Nov 2003 08:52:22 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Will trade money for quick help
Message-Id: <slrnbsgni6.mn2.dha@panix2.panix.com>
In article <12Rxb.5033$5d.218@bignews4.bellsouth.net>, Jenny wrote:
> I have one other change that I want to make that I can't figure out. I
> will paypal whoever can fix this last thing $25.
You have posted a job posting or a resume in a technical group.
Longstanding Usenet tradition dictates that such postings go into
groups with names that contain "jobs", like "misc.jobs.offered", not
technical discussion groups like the ones to which you posted.
Had you read and understood the Usenet user manual posted frequently to
"news.announce.newusers", you might have already known this. :) (If
n.a.n is quieter than it should be, the relevent FAQs are available at
http://www.faqs.org/faqs/by-newsgroup/news/news.announce.newusers.html)
Another good source of information on how Usenet functions is
news.newusers.questions (information from which is also available at
http://www.geocities.com/nnqweb/).
Please do not explain your posting by saying "but I saw other job
postings here". Just because one person jumps off a bridge, doesn't
mean everyone does. Those postings are also in error, and I've
probably already notified them as well.
If you have questions about this policy, take it up with the news
administrators in the newsgroup news.admin.misc.
http://jobs.perl.org may be of more use to you
Yours for a better usenet,
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
Sobriety is not an option
- Alex Page
------------------------------
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 5872
***************************************
