Re: Case of the Vanishing Symbol Tables

2001-12-11 Thread David Pisoni

IMHO, this looks similar to (though more catastrophic than) the problem I have been 
dealing with for some time now.

From the archive :
http://groups.yahoo.com/group/modperl/message/38622

There is a long thread about it.  It is presently unresolved.  (We're hoping for 
Divine intervention.  We'd settle for Doug. :-)

Good luck,
David



Re: PerlModule not updating %INC

2001-11-21 Thread David Pisoni

At 11.00 -0500 11/21/2001, Perrin Harkins wrote:
SNIP

David, are you using Apache::ReadConfig or anything that uses it?

- Perrin

Nope, not using ReadConfig.  And to address another point, the behavior is consistant 
regardless of whether or not PerlFreshRestart is on.

David



Re: PerlModule not updating %INC

2001-11-20 Thread David Pisoni

Hello,

I hate to keep banging this old drum, but since I was able to reproduce this problem 
(but not solve it), I figured I'd recycle it again.  Perrin said earlier that this was 
fixed in 1.26, but I am indeed using 1.26 and the problem persists.  Stas suggested 
upgrading perl to 5.6.1 -- I did so, recompiled mod_perl, and the problem persists.  I 
didn't try upgrading the perl on my darwin box, but the fact that I get the same 
result there is telling.

Can anyone tell me what the fix was from 1.25 to 1.26?  Maybe there's a clue there.

Thanks,
David



I'm still having this problem, and I've discovered that it is also happening on my 
darwin box.  This is enough to lead me to believe the problem is bona fide.

To recap: problem occurs on :
   Darwin (MacOS X) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26
   Red-Hat Linux (7.1) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26
   Red-Hat Linux (7.1) Perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26

Problem : PerlModule does not cause %INC to be updated, but 'use' does

Symptoms : Apache::StatINC does not work for said modules.  Said modules do not 
appear in Apache::Status loaded modules page, but do appear in the Inheritance tree.

Ideas?

Thanks,
David

Date: Thu, 18 Oct 2001 12:57:27 -0800
To: Stas Bekman [EMAIL PROTECTED]
From: David Pisoni [EMAIL PROTECTED]
Subject: Re: PerlModule not updating %INC
Cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED]
Bcc:
X-Attachments:

At 1.13 +0800 10/17/2001, Stas Bekman wrote:
David Pisoni wrote:

At 18.23 -0400 10/11/2001, Perrin Harkins wrote:

At 18.07 -0400 10/11/2001, Perrin Harkins wrote:

We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.

Are you sure?  There was a problem with %INC and PerlModule, but I

thought

it was fixed in 1.26.

- Perrin

Indeed, like I said, I tested it by dumping %INC myself -- the modules are

indeed missing when loaded with PerlModule.

No, I meant are you sure you're running 1.26?  Please doublecheck it, since
this sounds so much like the bug from the previous release.
- Perrin

Indeed, here's the signature from Apache::Status :

   Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) 
mod_perl/1.26

Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.)

Thanks,
David


So... any ideas on this one?


have you tried 5.6.1? 5.6.0 is very buggy.


Just tried it.  Fresh build of 5.6.1, and mod_perl 1.26 against it.  The problem 
persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded 
with PerlModule directives.

What should I try next. :-)

David

Original Message :

Hello,

We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.  We are running these 
on a RedHat Linux 7.1, kernel v2.4.2 system.

We have been doing development using mod_perl, but finding that Apache::StatINC was 
not working as expected (i.e., we needed to restart the web server in order to see 
our module changes in effect.)  Our apache config files preload all necessary modules 
at start time using the 'PerlModule' directive.  When I started peeking through 
Apache::Status I found that although all of our loaded modules appear in the 
Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded 
Modules section.  (I also did a test handler with a dump of the contents of %INC, 
and said modules were missing.)  The only modules of ours which DID appear were those 
which were ALSO called for with 'use' calls by other modules.

Out of curiosity, I took our configuration file and changed all the 'PerlModule' 
directives to 'use' calls (inside a Perl block), and lo and behold, they all 
appeared in %INC.

I could not find any documentation suggesting that the PerlModule directive would 
successfully load a module while circumventing %INC, nor do I recall in my previous 
projects developed using mod_perl having this problem.  (Although I've been away 
awhile -- maybe I forget.)

Any guidance?

Thanks,



Re: PerlModule not updating %INC

2001-11-20 Thread David Pisoni

At 18.02 -0500 11/20/2001, Robert Landrum wrote:
At 2:31 PM -0800 11/20/01, David Pisoni wrote:
 We have been doing development using mod_perl, but finding that Apache::StatINC 
was not working as expected (i.e., we needed to restart the web server in order to 
see our module changes in effect.)  Our apache config files preload all necessary 
modules at start time using the 'PerlModule' directive.  When I started peeking 
through Apache::Status I found that although all of our loaded modules appear in the 
Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded 
Modules section.  (I also did a test handler with a dump of the contents of %INC, 
and said modules were missing.)  The only modules of ours which DID appear were those 
which were ALSO called for with 'use' calls by other modules.




I just reread your original post... I think I may know what the problem is (maybe).  
Are you using Location handlers?

Location /whatever
SetHandler  perl-script
PerlModule My::Special::Module
PerlHandler My::Special::Module
/Location


If that is the case, My::Special::Module won't be loaded and compiled until the very 
first time that someone hits /whatever.

Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing 
blocks.  Although I do have 'PerlHandler' directives in Location and Files blocks, 
the modules they use are preloaded prior to the enclosing block.  We're hip to shared 
memory :-)

This explains the missing modules in %INC (I think), but it does not explain the 
problem with Apache::StatINC.

 Out of curiosity, I took our configuration file and changed all the 'PerlModule' 
directives to 'use' calls (inside a Perl block), and lo and behold, they all 
appeared in %INC.



And did this fix your problem with Apache::StatINC too?

Rob


Yes.  StatINC indeed uses %INC to do its magic.  StatINC's success or failure in this 
situation is merely a symptom though, not the real problem.

We could simply set our configuration files as I've described here, but I'm interested 
in mod_perl working correctly for everyone, hence I continue to beat this drum. :-)  I 
don't assume that the problem is unique to us -- rather I assume that we're the only 
ones experiencing it who both realize it and are doing something about it.

Thanks,
David



Re: PerlModule not updating %INC

2001-11-20 Thread David Pisoni

At 18.32 -0500 11/20/2001, Robert Landrum wrote:
 If that is the case, My::Special::Module won't be loaded and compiled until the 
very first time that someone hits /whatever.

Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing 
blocks.  Although I do have 'PerlHandler' directives in Location and Files 
blocks, the modules they use are preloaded prior to the enclosing block.  We're hip 
to shared memory :-)

It just hit me That is why Apache::StatINC isn't working.

We use Apache::StatINC on our development server, but we never preload any modules... 
 We just use

Location /whatever
SetHandler  perl-script
PerlHandler My::Special::Module
/Location

and Apache::StatINC works.

If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC 
would intentionally overwrite that shared memory and destroy the purpose for using 
PerlModule in the first place.

If this is true, it is a change from prior behavior.  (And a bit distressing.)  I for 
one would not complain of Apache::StatINC dirtying memory pages -- I'm really only 
concerned with shared memory on a production server, and I wouldn't run StatINC 
outside of the development environment.  Besides, I'm assuming that if I do my trick 
of calling 'use' in a Perl block (which DOES update %INC) that the module code pages 
are still shared.

What is more distressing though is that StatINC may not be the only consumer of %INC.  
(e.g., Apache::Status does not report these modules in Loaded Modules)  The real 
trouble is that it is deviating from Doing the Right ThingĀ by perl.

I could be wrong...  but I think that the answer is that It's not a bug, it's a 
feature, and that the behavior is actually correct.


For the above reasons, I hope you are wrong. :-)  But you may be right!

David



Re: mod_dir DirectoryIndex vs. $r-uri() manipulation

2001-11-09 Thread David Pisoni

* David Pisoni [EMAIL PROTECTED] wrote:
 Hello again modperlers,

 I am using perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26.

 I have an interesting problem which maybe someone could shed some
 light on :

 I have an early phase handler (can be done as either a
 PerlPostReadRequestHandler or a PerlTransHandler) which manipulates
 the request URI.  The purpose of the handler is to strip out the
 first segment of the URI path and employ that as a user type
 string.  I presently have it as a TransHandler which returns
 DECLINED, expecting Apache to continue URI translation based on the
 new URI setting.  For almost all types of URIs this functionality is
 working: it works for files in the DocumentRoot, it works for
 PerlHandlers declared in Location blocks, and it works for Alias
 mapped paths. Only one thing breaks...

 The one URI type which isn't resolved correctly is
 DirectoryIndex-resolved paths.  If mod_autoindex is on, then an
 AutoIndex directory listing is displayed.  If mod_autoindex is off,
 a NOT FOUND error is displayed.  If I access the same directory
 without the URI manipulation (and without the extra user type
 segment), the DirectoryIndex-specified file is served as expected.

 I thought to myself, maybe the mod_dir resolution wants to be before
 any declared PerlTransHandler (even though mod_autoindex comes
 after) so I tried moving my handler to a PostReadRequestHandler.
 Same effect though -- something is short-circuiting the
 DirectoryIndex function of mod_dir.

 Anyone else encounter this?  Any ideas how to resolve?

Don't try to strip the uri in sub requests ($r-is_main()).

   --Nikolaus

I don't.  Indeed, if I did, other parts of the system would fail terribly.  My handler 
begins with :

return undef unless ($r-is_main())

and proceeds as described above.

Thanks,
David




mod_dir DirectoryIndex vs. $r-uri() manipulation

2001-11-08 Thread David Pisoni

Hello again modperlers,

I am using perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26.

I have an interesting problem which maybe someone could shed some light on :

I have an early phase handler (can be done as either a PerlPostReadRequestHandler or a 
PerlTransHandler) which manipulates the request URI.  The purpose of the handler is to 
strip out the first segment of the URI path and employ that as a user type string.  
I presently have it as a TransHandler which returns DECLINED, expecting Apache to 
continue URI translation based on the new URI setting.  For almost all types of URIs 
this functionality is working: it works for files in the DocumentRoot, it works for 
PerlHandlers declared in Location blocks, and it works for Alias mapped paths. Only 
one thing breaks...

The one URI type which isn't resolved correctly is DirectoryIndex-resolved paths.  If 
mod_autoindex is on, then an AutoIndex directory listing is displayed.  If 
mod_autoindex is off, a NOT FOUND error is displayed.  If I access the same 
directory without the URI manipulation (and without the extra user type segment), 
the DirectoryIndex-specified file is served as expected.

I thought to myself, maybe the mod_dir resolution wants to be before any declared 
PerlTransHandler (even though mod_autoindex comes after) so I tried moving my handler 
to a PostReadRequestHandler.  Same effect though -- something is short-circuiting the 
DirectoryIndex function of mod_dir.

Anyone else encounter this?  Any ideas how to resolve?

Thanks,
-- 
David Pisoni -- [EMAIL PROTECTED]

Education is a progressive discovery of our own ignorance.
-Will Durant, historian (1885-1981)



Re: PerlModule not updating %INC

2001-10-30 Thread David Pisoni

I'm still having this problem, and I've discovered that it is also happening on my 
darwin box.  This is enough to lead me to believe the problem is bona fide.

To recap: problem occurs on :
Darwin (MacOS X) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26
Red-Hat Linux (7.1) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26
Red-Hat Linux (7.1) Perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26

Problem : PerlModule does not cause %INC to be updated, but 'use' does

Symptoms : Apache::StatINC does not work for said modules.  Said modules do not appear 
in Apache::Status loaded modules page, but do appear in the Inheritance tree.

Ideas?

Thanks,
David

Date: Thu, 18 Oct 2001 12:57:27 -0800
To: Stas Bekman [EMAIL PROTECTED]
From: David Pisoni [EMAIL PROTECTED]
Subject: Re: PerlModule not updating %INC
Cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED]
Bcc:
X-Attachments:

At 1.13 +0800 10/17/2001, Stas Bekman wrote:
David Pisoni wrote:

At 18.23 -0400 10/11/2001, Perrin Harkins wrote:

At 18.07 -0400 10/11/2001, Perrin Harkins wrote:

We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.

Are you sure?  There was a problem with %INC and PerlModule, but I

thought

it was fixed in 1.26.

- Perrin

Indeed, like I said, I tested it by dumping %INC myself -- the modules are

indeed missing when loaded with PerlModule.

No, I meant are you sure you're running 1.26?  Please doublecheck it, since
this sounds so much like the bug from the previous release.
- Perrin

Indeed, here's the signature from Apache::Status :

Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) 
mod_perl/1.26

Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.)

Thanks,
David


So... any ideas on this one?


have you tried 5.6.1? 5.6.0 is very buggy.


Just tried it.  Fresh build of 5.6.1, and mod_perl 1.26 against it.  The problem 
persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded 
with PerlModule directives.

What should I try next. :-)

David




Re: PerlModule not updating %INC

2001-10-18 Thread David Pisoni

At 1.13 +0800 10/17/2001, Stas Bekman wrote:
David Pisoni wrote:

At 18.23 -0400 10/11/2001, Perrin Harkins wrote:

At 18.07 -0400 10/11/2001, Perrin Harkins wrote:

We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.

Are you sure?  There was a problem with %INC and PerlModule, but I

thought

it was fixed in 1.26.

- Perrin

Indeed, like I said, I tested it by dumping %INC myself -- the modules are

indeed missing when loaded with PerlModule.

No, I meant are you sure you're running 1.26?  Please doublecheck it, since
this sounds so much like the bug from the previous release.
- Perrin

Indeed, here's the signature from Apache::Status :

 Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) 
mod_perl/1.26

Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.)

Thanks,
David


So... any ideas on this one?


have you tried 5.6.1? 5.6.0 is very buggy.


Just tried it.  Fresh build of 5.6.1, and mod_perl 1.26 against it.  The problem 
persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded 
with PerlModule directives.

What should I try next. :-)

David



Re: PerlModule not updating %INC

2001-10-12 Thread David Pisoni

At 18.23 -0400 10/11/2001, Perrin Harkins wrote:
  At 18.07 -0400 10/11/2001, Perrin Harkins wrote:
We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.
  
  Are you sure?  There was a problem with %INC and PerlModule, but I
thought
  it was fixed in 1.26.
  
  - Perrin
 
  Indeed, like I said, I tested it by dumping %INC myself -- the modules are
indeed missing when loaded with PerlModule.

No, I meant are you sure you're running 1.26?  Please doublecheck it, since
this sounds so much like the bug from the previous release.
- Perrin

Indeed, here's the signature from Apache::Status :

   Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) 
mod_perl/1.26

Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.)

Thanks,
David

So... any ideas on this one?

David



PerlModule not updating %INC

2001-10-11 Thread David Pisoni

Hello,

We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.  We are running these 
on a RedHat Linux 7.1, kernel v2.4.2 system.

We have been doing development using mod_perl, but finding that Apache::StatINC was 
not working as expected (i.e., we needed to restart the web server in order to see our 
module changes in effect.)  Our apache config files preload all necessary modules at 
start time using the 'PerlModule' directive.  When I started peeking through 
Apache::Status I found that although all of our loaded modules appear in the 
Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded 
Modules section.  (I also did a test handler with a dump of the contents of %INC, and 
said modules were missing.)  The only modules of ours which DID appear were those 
which were ALSO called for with 'use' calls by other modules.

Out of curiosity, I took our configuration file and changed all the 'PerlModule' 
directives to 'use' calls (inside a Perl block), and lo and behold, they all 
appeared in %INC.

I could not find any documentation suggesting that the PerlModule directive would 
successfully load a module while circumventing %INC, nor do I recall in my previous 
projects developed using mod_perl having this problem.  (Although I've been away 
awhile -- maybe I forget.)

Any guidance?

Thanks,
-- 
David Pisoni

One machine can do the work of fifty ordinary men. No machine can do the work of one 
extraordinary man. -Elbert Hubbard, author, editor, printer (1856-1915)



Re: PerlModule not updating %INC

2001-10-11 Thread David Pisoni

At 18.07 -0400 10/11/2001, Perrin Harkins wrote:
  We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.

Are you sure?  There was a problem with %INC and PerlModule, but I thought
it was fixed in 1.26.

- Perrin

Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed 
missing when loaded with PerlModule.

Enjoy,
David



Re: PerlModule not updating %INC

2001-10-11 Thread David Pisoni

At 18.23 -0400 10/11/2001, Perrin Harkins wrote:
  At 18.07 -0400 10/11/2001, Perrin Harkins wrote:
   We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26.
 
 Are you sure?  There was a problem with %INC and PerlModule, but I
thought
 it was fixed in 1.26.
 
 - Perrin

 Indeed, like I said, I tested it by dumping %INC myself -- the modules are
indeed missing when loaded with PerlModule.

No, I meant are you sure you're running 1.26?  Please doublecheck it, since
this sounds so much like the bug from the previous release.
- Perrin

Indeed, here's the signature from Apache::Status :

Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) 
mod_perl/1.26

Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.)

Thanks,
David



method POST, STDIN, input record separator

2001-09-25 Thread David Pisoni

Hello all,

Long time no chat.

I've found what appears to be a problem in mod_perl --
I am using mod_perl 1.26 with Apache 1.3.20, on RH Linux 7.1 (kernel
2.4.3).
It appears that when I use STDIN (or STDIN-getline(), for that
matter) to read input from a POST that the input record separator is
not respected on input. In other words, if I write :

  $line = STDIN;

$line will be equal to the entire POST data, newlines and all.  Even
if I explicitly write :

  local $/ = \n;
  $line = STDIN;

I get the same results.

Anyone else run into this problem?  Workaround? (Other than
re-implementing getline() with a character-by-character read.)

Thanks,

-- 
David Pisoni

What is to give light must endure burning. - Viktor Frankl, author,
neurologist and psychiatrist, Holocaust survivor (1905-1997)