Perrin Harkins schreef:
On 7/11/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
By the way, I've used push() to add my path to @INC before. But that
didn't work out.
It should work fine. The reason people typically use unshift for this
is that it lets modules in your local path override ones i
On 7/11/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
By the way, I've used push() to add my path to @INC before. But that
didn't work out.
It should work fine. The reason people typically use unshift for this
is that it lets modules in your local path override ones in the system
path.
- Per
Perrin Harkins schreef:
On 7/11/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
Thanks. I will try that. So basicly, the modules that are loaded at the
first request will stay in memory, but @INC will get reset?
Yes. It's a simulation of CGI behavior. The only reason your CGI
scripts don't ha
On 7/11/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
Thanks. I will try that. So basicly, the modules that are loaded at the
first request will stay in memory, but @INC will get reset?
Yes. It's a simulation of CGI behavior. The only reason your CGI
scripts don't have this problem is that t
> Wow. I never noticed it. In my app I have runmode that shows me %ENV and
> @INC. At the first request my custom path was in there. And at the
> second request it wasn't. But after a few more requests it's still
> there. Weird behaviour?
All that means is that you're hitting a new child for t
Perrin Harkins schreef:
On 7/11/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
I add to @INC with " use lib qw(/my/path) ". All the other modules I
load continue to work fine. Just those that use lazy loading fail
infrequently.
Okay, I think I see the problem. When you change @INC during a
re
On 7/11/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
I add to @INC with " use lib qw(/my/path) ". All the other modules I
load continue to work fine. Just those that use lazy loading fail
infrequently.
Okay, I think I see the problem. When you change @INC during a
request, the change only la
Perrin Harkins schreef:
On 7/7/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
Because in my error messages it clearly says it can't find the modules
in @INC. Then it shows all the paths in @INC and my custom lib isn't set
there, instead, @INC is at it's original state.
Okay, you said you don't
On 7/7/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
Because in my error messages it clearly says it can't find the modules
in @INC. Then it shows all the paths in @INC and my custom lib isn't set
there, instead, @INC is at it's original state.
Okay, you said you don't add to @INC at startup.
Yes,
Because in my error messages it clearly says it can't find the modules
in @INC. Then it shows all the paths in @INC and my custom lib isn't set
there, instead, @INC is at it's original state.
Christiaan Kras
Perrin Harkins schreef:
On 7/6/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
On 7/6/07, Christiaan Kras <[EMAIL PROTECTED]> wrote:
I'm 100% sure it happens in the modules that use lazy loading
(eval(require "module.pm")). Somehow @INC gets reset.
Are you sure @INC is getting reset? Sometimes people have this
problem because the user that apache runs as (usually "nobody
Hi,
My webhost allows me to use mod_perl (Apache 2 server by the way, Fedora
distro). And I'm glad I can because it speeds up my perl scripts a lot.
I've created a website that's based on CGI::Application,
Template-Toolkit and DBIx::Class. All works fine.
Those modules, including my own, are
12 matches
Mail list logo
