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: 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: 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 ' 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: Apache::Registry - a thought
Oh ghod, what have I started... :) I promise not to add footnotes to my messages in future... /Pete/
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/
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: 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.'"