>By the way, it's pretty reasonable to expect that someone who intends to
>run your code under mod_perl will be able to either add a use lib
>statement to httpd.conf or put your libs in /lib/perl/ which
>is automatically added to @INC. Both of those avoid this issue
I actually ended up using "Perl
>Hmm. You must have some things inside a BEGIN or that are called from a
>"use" that need these libs to be in @INC during the compile phase.
Yeah, I'm not entirely sure what it is - I'm not using any BEGIN's myself.
>More to the point, I would expect you to have the same problem that you
>had wi
On Sat, 2004-02-21 at 20:43, Morbus Iff wrote:
> Well, without the BEGIN, running it as a normal CGI script failed entirely,
> with the scripts not being able to find the modules.
Hmm. You must have some things inside a BEGIN or that are called from a
"use" that need these libs to be in @INC duri
>> For what it's worth, I had to do this instead:
>>
>> BEGIN { unshift(@INC, qw(lib extlib)); }
>
>That's odd, because that's almost exactly equivalent to a "use lib"
>call. Are you running this under PerlRun? PerlRun executes BEGIN
>blocks every time, but Registry only executes them once. It
Morbus Iff wrote:
For what it's worth, I had to do this instead:
BEGIN { unshift(@INC, qw(lib extlib)); }
That's odd, because that's almost exactly equivalent to a "use lib"
call. Are you running this under PerlRun? PerlRun executes BEGIN
blocks every time, but Registry only executes them on
>The only reason it doesn't work the second time is that "use lib 'lib'"
>happens at compile time. It's like a BEGIN block. To make it happen
>every time, you could just do this:
>
>unshift(@INC, qw(lib extlib));
For what it's worth, I had to do this instead:
BEGIN { unshift(@INC, qw(lib extl
At 7:53 PM -0500 2/19/04, petersm wrote:
>Morbus Iff wrote:
>> So, in my case, it appears that eval'ing the module in the .cgi script
>> is my only solution, based on this bit from the porting guidelines:
>>
>> When running under mod_perl, once the server is up @INC is frozen
>> and cannot be u
Morbus Iff wrote:
> So, in my case, it appears that eval'ing the module in the .cgi script
> is my only solution, based on this bit from the porting guidelines:
>
> When running under mod_perl, once the server is up @INC is frozen
> and cannot be updated. The only opportunity to temporarily mo
On Thu, 2004-02-19 at 18:33, Morbus Iff wrote:
> So, in my case, it appears that eval'ing the module in the .cgi script
> is my only solution, based on this bit from the porting guidelines:
>
> When running under mod_perl, once the server is up @INC is frozen
> and cannot be updated. The only
At 6:27 PM -0500 2/19/04, Morbus Iff wrote:
>>You are either getting the wrong module name in some cases, or it is not
>>able to read the module file for some reason. Just check $@ for the
>>message and find out.
>
> Can't locate LibDB/DB/MySQL.pm in @INC (@INC contains:
> /usr/lib/perl5/5.8.0/i58
>You are either getting the wrong module name in some cases, or it is not
>able to read the module file for some reason. Just check $@ for the
>message and find out.
Interesting. I got:
Can't locate LibDB/DB/MySQL.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/li
On Thu, 2004-02-19 at 17:38, Morbus Iff wrote:
> * the first load of index.cgi uses no DB calls (well,
> it does "use LibDB::DB", but DB.pm never gets around
> to eval'ing MySQL.pm), so things are cached without it.
>
> * with all the modules and whatnot cached in the child,
> a "u
>> I don't, however, do any error checking on that eval.
>
>Jinx!
Heh, heh :)
>> that if a) the eval fails or it gets cached or whatever, then
>> b) I'd be returning a blessed object for a module that hasn't
>> been loaded. *That* could cause the ->connect to not exist,
>> thus causing my error. R
On Thu, 2004-02-19 at 17:01, Morbus Iff wrote:
> I don't, however, do any error checking on that eval.
Jinx!
> It seems
> that if a) the eval fails or it gets cached or whatever, then
> b) I'd be returning a blessed object for a module that hasn't
> been loaded. *That* could cause the ->connect t
On Thu, 2004-02-19 at 16:54, Morbus Iff wrote:
> * LibDB::DB is correctly determining the database type.
>
> * LibDB::DB is correctly returning a blessed
> class for that database type (LibDB::DB::MySQL).
>
> * LibDB::DB::MySQL->connect does exist.
>
> * LibDB::DB::MySQL->connect doe
>Alrighty. I've yet to figure out what my ->connect problem [1] is.
>All my settings caching problems have been fixed, as I've yet to
>duplicate the issue in about 300 to 400 loads. Anywhere I should
>look? What I know:
>
>[1] http://groups.yahoo.com/group/modperl/message/57303
> Program fragme
>>You can learn that you don't have a problem with globals that are in the
>>current script's name space and not declared explicitly in any package.
>>You may still have problems with globals in other packages, or closures.
>
>This, as well as http://groups.yahoo.com/group/modperl/message/57338,
>p
>> In an attempt to disprove my sanity, I did a quick swap out of
>> Apache::Registry for Apache::PerlRun, expecting that a good portion
>> of my problems [1] would go away. Oddly, they didn't. In fact, there
>> seemed to be no difference whatsoever. Can I learn anything from this?
>
>You can learn
On Wed, 2004-02-18 at 16:56, Morbus Iff wrote:
> In an attempt to disprove my sanity, I did a quick swap out of
> Apache::Registry for Apache::PerlRun, expecting that a good portion
> of my problems [1] would go away. Oddly, they didn't. In fact, there
> seemed to be no difference whatsoever. Can I
In an attempt to disprove my sanity, I did a quick swap out of
Apache::Registry for Apache::PerlRun, expecting that a good portion
of my problems [1] would go away. Oddly, they didn't. In fact, there
seemed to be no difference whatsoever. Can I learn anything from this?
[1] http://groups.yahoo.com/
20 matches
Mail list logo
