Re: Regarding modperl installation (fwd)
G.W. Haywood [EMAIL PROTECTED] wrote:
There have been a few problems reported with 5.6 and I have seen one
or two myself.
Although the problems which I saw were largely the result of slightly
dubious coding practices and were easily fixed, some people had more
serious problems and it's why I moved to 5.7 for development.
Dunno if it counts as a dubious coding practice, but I've come across
precisely one problem porting the (large) Perl/mod_perl system I maintain
at Motorola from 5.005_03 to 5.6.1:
sub foo(@);
foo {} qw(BAR BAZ);
no longer works (from 5.6.0, actually), presumably because qw() actually
generates a list at compile time, rather than translating to split, and
the equivalent construct foo {} ('BAR', 'BAZ'); doesn't compile in
5.005_03 either.
I was slightly doubtful about 5.6.0 as a major release, but I would regard
5.6.1 as safe for production use as long as you treat some of the new
bleeding edge features with sensible caution.
Pete
Re: Syntax errors across multiple virtual hosts with separate codebase
Chris Winters [EMAIL PROTECTED] wrote: I'm not sure how you create your database handles (in a central location then passed around, or in each handler as you need it), but in MySQL (as with other databases) you can execute a 'use dbname' to start using a different database. FWIW, MySQL is quite happy performing queries on foreign databases through DBI; I've needed to do this to perform queries that span tables on multiple databases. Not sure of the performance overhead, but if you fully qualify your fields (as in db.table.field) it shouldn't matter what database your handle is actually opened on. Pete
Re: files having same ext, different handler based on partial name
Surat Singh Bhati [EMAIL PROTECTED] wrote:
Any trick to find out that a given CGI is working under
Apache::PerlRun or Apache::Registry. The $ENV{MOD_PERL} says
that script is working under mod_perl, but it does not says it
is working under Perlrun Registry.
Use caller - at the top of your script:
my @env=caller;
my $env=@env ? $env[0] : 'CGI';
$env will be one of 'CGI', 'Apache::Registry' or 'Apache::PerlRun'. Use
$env=(caller)[0] if you always run under mod_perl.
Pete
Re: Apache::Registry - a thought
Oh ghod, what have I started... :) I promise not to add footnotes to my messages in future... /Pete/
Apache::Registry - a thought
I've been off this list for over a year, so I may be covering ground that
I've failed to find in the archives, but whatever...
I've had occasion to examine the internals of Apache::Registry recently[1]
and have been reminded of the unfeasably long package names that it
generates for scripts.
It occurs to me that there would be no overhead to speak of in using a
sequence number, given that Apache::Registry already maintains a hash for
its generated package names for mtime checks. Something like:
my $script=
$Apache::Registry-{$script_name}||=
{seq = ++$Apache::Registry::seq, mtime = $mtime+1};
my $package=sprintf Apache::MAIN::S%04d, $script-{seq};
$r-log_error(Apache::Registry::handler package $package)
if $Debug $Debug 4;
$r-chdir_file;
unless ($script-{mtime} = $mtime) {
$script-{mtime}=$mtime;
$package=sprintf Apache::MAIN::S%04d, $script-{seq};
# compile into $package
}
my $old_status = $r-status;
my $cv = \{$package\::handler};
eval { {$cv}($r, @_) } if $r-seqno;
# and so on...
Seems a lot clearer to me than what we now have (particularly if a script
directory is way down the directory hierarchy), gets round the need for
name mangling, and the real script name is still there in the file field
of stack frames for diagnostic purposes.
Pete Jordan
[1] for my Perl exception package (yes, another one :) which, in its
development version, now mostly does the Right Thing for mod_perl. See
http://sourceforge.net/projects/perlexception/ for the curious.
Re: Exception modules
Matt Sergeant [EMAIL PROTECTED] wrote:
It doesn't seem any different from Error.pm to me, except in syntax.
Maybe you could expand on why/where it is different?
OK, yes, it *is* very similar in principle - I would perhaps have been
better to have added to Graham's code, but I suffer from False Hubris :)
My code coexists better with CGI and, in particular, mod_perl
(Apache::Registry and Apache::PerlRun) - adding code for HTML output is
trivial, and I at least attempt to cope with exceptions raised within
exception handlers and finally blocks, but apart from that there are
minor advantages either way: I prefer my syntax (but then I would :) and
allow matching of exceptions by regexp against error text and exception
name as well as class; Error.pm allows try {} to return lists as well as
scalars (something I may add), has an otherwise clause for which I can
see no particular use at all and I haven't (yet) subclassed Exception.pm
to provide the sort of functionality Error::IO provides.
The implementations are, of course, significantly different internally;
which is better I leave up to the reader - I do trap $SIG{__DIE__} which
many would regard as a hanging offence (but then so does Apache::Debug).
/Pete/
Re: Attempt to free unreferenced scalar (again)
Matt Sergeant wrote: Hmm.. maybe you have an original 5.005 (and no patchlevel) then. I seriously recommend a perl upgrade. There were bugs there that have since been fixed, and some of those may lead to your error. Happens here on Perl 5.005_03, Apache 1.3.6, mod_perl 1.21 all built locally with gcc 2.95 under Solaris 2.6. It's odd: used to happen a lot on server shutdown (ie. when doing an apachectl graceful), stopped pretty much altogether for a while and just started again this week under normal operation as well as shutdown. Nothing changed at this end that I can think of... Pete -- use Disclaimer::Standard; # Motorola GSM Software Factory my $phone='+44 1793 564450';# "'Not twisted,' Salzy once said of my $fax='+44 1793 566918'; # her own passion, 'it is helical. my $mobile='+44 7973 725120'; # That sounds better.'"
