[26332] in Perl-Users-Digest
Perl-Users Digest, Issue: 8507 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 10 14:05:19 2005
Date: Mon, 10 Oct 2005 11:05:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 10 Oct 2005 Volume: 10 Number: 8507
Today's topics:
Re: Can't locate warnings.pm in @INC <noreply@gunnar.cc>
Re: Can't locate warnings.pm in @INC <noreply@gunnar.cc>
Re: Can't locate warnings.pm in @INC <jds@myob.com>
Re: parsing postfix bounce back emails from log <scobloke2@infotop.co.uk>
Re: threads, XSUB allocated memory, destructors, destru <please@no_mail.com>
Re: threads, XSUB allocated memory, destructors, destru xhoster@gmail.com
Re: Whats the most complicate RegEX that can be done? <babacio@free.fr>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 10 Oct 2005 12:48:58 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Can't locate warnings.pm in @INC
Message-Id: <3quv53Fgs16dU1@individual.net>
Julia De Silva wrote:
> I'm getting
> index.cgi: Can't locate warnings.pm in @INC ..............
> when running script on this server.
> **
> *Perl Executable:*
> perl
> *Perl Version:* 5.00503
The warnings pragma was introduced in Perl 5.6.0.
> The script does not contain -w on Shebang line,
That's irrelevant, since it's how warnings often are enabled in programs
written for pre 5.6.0 versions (-w does not require warnings.pm).
> nor does
> it have uses Warnings; (Perl 5.6 onwards ?)
>
> but it has
>
> use CGI qw(:standard);
> use CGI::Carp qw(fatalsToBrowser);
> use DBI;
> use Time::localtime;
It would surprise me if any of those modules requires 5.006, but the
answer is probably in the complete error message.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 10 Oct 2005 13:21:34 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Can't locate warnings.pm in @INC
Message-Id: <3qv161FgpptgU3@individual.net>
Gunnar Hjalmarsson wrote:
>>
>> use CGI qw(:standard);
>> use CGI::Carp qw(fatalsToBrowser);
>> use DBI;
>> use Time::localtime;
>
> It would surprise me if any of those modules requires 5.006,
Noticed that the latest version of DBI does require 5.006... Maybe
somebody has upgraded that module without upgrading the version of Perl
accordingly.
But, again, no reason to keep guessing. Read the _complete_ error message.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 10 Oct 2005 11:30:25 GMT
From: "Julia De Silva" <jds@myob.com>
Subject: Re: Can't locate warnings.pm in @INC
Message-Id: <lhs2f.313$U9.99@fe3.news.blueyonder.co.uk>
>>> use CGI qw(:standard);
>>> use CGI::Carp qw(fatalsToBrowser);
>>> use DBI;
>>> use Time::localtime;
>>
>> It would surprise me if any of those modules requires 5.006,
>
> Noticed that the latest version of DBI does require 5.006... Maybe
> somebody has upgraded that module without upgrading the version of Perl
> accordingly.
>
> But, again, no reason to keep guessing. Read the _complete_ error message.
Many thanks for your help. The answer is below and you are exactly right !!
Sometimes, if I could just read the obvious ..... Sorry 'bout that. Now to
get on the phone to the ISP.
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.005/i386-linux/DBD/mysql/GetInfo.pm line 20.
------------------------------
Date: Mon, 10 Oct 2005 13:12:10 +0000 (UTC)
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: parsing postfix bounce back emails from log
Message-Id: <didpba$o4u$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com>
gooogoo wrote:
> I have a little script going to tell me why a email bounced.
>
> i feel like Im taking the long road.
>
> Heres what I do.
>
> First I open the file and then do.
>
>
> while (<FILE>){
>
> if($_ =~ m/From\sMAILER\-DAEMON/){
> $error1 = 'unknown';
>
> }elsif($_ =~ m/said\:\s(.*?)\s/){
> $status_code = $1;
>
> }elsif($_ =~ m/Invalid\srecipient/){
> $error1 = 'Invalid Receipient';
>
> }elsif($_ =~ m/Mailbox\sunavailable/i){
> $error1 = 'Mailbox Unavailable';
>
> and so on and sooooo on. Ending up with a huge list of defined errors.
>
>
> I first match MAILER DAEMON coz every bounce back starts with that, so its a
> border to work with.
>
> I guess to cut down on the elsif statements I would whack the regex searches
> into an array.
>
> Any helpful tips.
>
>
perldoc -q "case statement"
------------------------------
Date: 10 Oct 2005 15:22:52 +0200
From: Andrew Torda <please@no_mail.com>
Subject: Re: threads, XSUB allocated memory, destructors, destruction
Message-Id: <lyu0fp33rn.fsf@bern.zbh.uni-hamburg.de>
Greetings from the original poster
> Thanks for taking the time to provide that example. That about wraps it up
> for me ..... wonder how the op is getting on with this :-)
I can tell you... Not very happy.
Using CLONE_SKIP() does what it should. It stops you being
destroy()ed. Unfortunately, "man perlmod" says your objects
"will be copied as unblessed, undef values" and "if the
child thread needs to make use of the objects, then a more
sophisticated approach is needed.
OK.
Maybe I should write my own CLONE(), although this is a bad
idea. Perldoc Threads::shared says that "Currently CLONE is
called with no parameters other than the invocant package
name". This means you can't get to the address you need to do the
copying. It is a catastrophically ugly approach to a large amount
of data which should be shared since it is passed to threads for
use in some calculations.
We are dealing with arrays of blessed objects. They should
be shared between threads, but then one hits the problem
that ""bless" is not supported on shared references. In other
words, if one has a reference to a 2D array of blessed objects
and says p $$coords[0][0], you get something like
MyPtr=SCALAR(0x85efe8c). If you then mark it as shared,
"share $coords", and try the print statement, you are bluntly
told, "Invalid value for shared scalar at ...".
So, that is the answer to the question, "how is the op getting
on with this".
Andrew
------------------------------
Date: 10 Oct 2005 16:36:23 GMT
From: xhoster@gmail.com
Subject: Re: threads, XSUB allocated memory, destructors, destruction
Message-Id: <20051010123623.518$4X@newsreader.com>
Andrew Torda <please@no_mail.com> wrote:
> Greetings from the original poster
> > Thanks for taking the time to provide that example. That about wraps it
> > up for me ..... wonder how the op is getting on with this :-)
>
> I can tell you... Not very happy.
> Using CLONE_SKIP() does what it should. It stops you being
> destroy()ed. Unfortunately, "man perlmod" says your objects
> "will be copied as unblessed, undef values" and "if the
> child thread needs to make use of the objects, then a more
> sophisticated approach is needed.
Another possible way to prevent the children threads from trying to
free the data is to have the threads bail out with a POSIX::_exit.
I do this in forked processes all the time (where the goal is to prevent
the costs of cleaning up, which can be very great for large amounts of
data, especially with cow), but don't know how it will work in threads.
> OK.
> Maybe I should write my own CLONE(), although this is a bad
> idea. Perldoc Threads::shared says that "Currently CLONE is
> called with no parameters other than the invocant package
> name". This means you can't get to the address you need to do the
> copying.
You can, but you need to store that address (those addresses) somewhere
other than in the objects themselves (or you need to store the objects
themselves somewhere in the package).
> It is a catastrophically ugly approach to a large amount
> of data which should be shared since it is passed to threads for
> use in some calculations.
Exactly what kind of sharing are you doing? Is most the sharing read
only or does each thread need to be able to write such that the other
threads can see the changes?
If only the "master" thread need to write to this large amount of data,
and if you are using a unix-like system, then you could try forking
rather than threads. Perl may not know how to clone XSUB data, but the
kernel does know how to. And because of cow (copy on write), forked data
can live in the same RAM as the original until it starts getting changed.
>
> We are dealing with arrays of blessed objects. They should
> be shared between threads, but then one hits the problem
> that ""bless" is not supported on shared references. In other
> words, if one has a reference to a 2D array of blessed objects
> and says p $$coords[0][0], you get something like
> MyPtr=SCALAR(0x85efe8c). If you then mark it as shared,
> "share $coords", and try the print statement, you are bluntly
> told, "Invalid value for shared scalar at ...".
You should not get that from a print statement. That error occurs either
when you assign to a shared variable, or when you share a variable. Not
when you read from a variable.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Mon, 10 Oct 2005 12:53:47 +0200
From: Babacio <babacio@free.fr>
Subject: Re: Whats the most complicate RegEX that can be done?
Message-Id: <m2wtkltzgk.fsf@baba.ba>
"Matt Garrish"
>> What is the most complicated Regular Expression possible?
>
> The regular expression that will destroy us all. But if you write it, you'll
> destroy us all and so never know that you succeeded.
Shhh, that's the secret name of God.
--
Bé erre hue ixe eu elle, Bruxelles.
------------------------------
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 8507
***************************************
