date:20031021

Thanks Vivek & Stas.

Actually, as I said to Stas before, the module I'm working on is not a 
"port" of Sandwich. It might be called a functional replacement to 
Sandwich, though.

It's a TT compliant wrapper filter which allows wrapping resources (cgi or 
static) without them knowing anything about it.

In addition to that, it will probably also support the HEADER && FOOTER 
parameters, the same way Sandwich does, to ease transition for folks.

It's not sure it will be possible to fully support the Sandwich API 
(especially concerning procedural interface from within handlers, which is 
really obsolete).

But if turns out to be so, the module can be called Sandwich then. 
Otherwise, I am inclined towards picking another name.



Cheers,

Ayhan



At 19:17 20/10/2003, Stas Bekman wrote:

SB> modperl list... Also it's probably a good idea to ask the owner of 
SB> Apache::Sandwich whether they aren't working on a mp2 port already.
I am not.  Feel free to adopt it.
Personally, I don't use it anymore in preference to a real templating
system such as Template Toolkit.
Thanks Vivek. So Ayhan it's all yours if you decide to adopt the name.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH mp2] Skip getppid() test on Win32

Steve Hay wrote:
Steve Hay wrote:

The attached patch skips the new getppid() test (perl/api.t) on Win32 
since getppid() is unimplemented on this platform! 
Weird:

% perldoc -f getppid
=item getppid
Returns the process id of the parent process.

Is it a bug in perl? why a non-portable function lives in perlfunc.pod?

Doesn't POSIX.pm provide a similar implementation?

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: porting Sandwich to mp2

Ayhan Ulusoy wrote:

But if turns out to be so, the module can be called Sandwich then. 
Otherwise, I am inclined towards picking another name.
Just an idea. Use a different name, but include a subclass of that module 
which can be called Sandwich as a back-compat module which will work as 
before. But probably it's not worth the effort ;)

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH mp2] Skip getppid() test on Win32

2003-10-21 Thread Randy Kobes

On Tue, 21 Oct 2003, Stas Bekman wrote:

> Steve Hay wrote:
> > Steve Hay wrote:
> >
> >> The attached patch skips the new getppid() test (perl/api.t) on Win32
> >> since getppid() is unimplemented on this platform!
>
> Weird:
>
> % perldoc -f getppid
> =item getppid
>
> Returns the process id of the parent process.
>
> Is it a bug in perl? why a non-portable function lives in perlfunc.pod?

I think the portability issues have been relegated to
perlport.pod, which reports that getppid is indeed
unimplemented on Win32.

> Doesn't POSIX.pm provide a similar implementation?

It's also unimplemented under POSIX.pm.

-- 
best regards,
randy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Testing and smoking leave a PID file behind

Steve Hay wrote:
Stas Bekman wrote:

Stas Bekman wrote:

Also this core files scan, is it relevant at all to WIN32? When you 
get a coredump, do you get a core file? 




No, there's no core files on Win32.  "Dr Watson's log files" would 
be the closest thing I suppose, but you don't really want to go 
there.  Perhaps if we skip the coredump scan on Win32 then the 
problem of the "wrong" PID file being picked up would go away?




I suggest we first fix the problem of the wrong path, since it may 
bite us elsewhere later.

Next please submit a patch to skip core_scan (there are two versions 
in TestRun), which will make SMOKE much faster on win32.


Argh, looks like I should have waited for the wrong path issue fix, 
before committing the skip of the core_scan on win32. Applying a 
reversed patch of this should give you the previous state back:
http://marc.theaimsgroup.com/?l=apache-test-cvs&m=106669945815816&w=2 


"Argh", indeed!

I just spent quite a while trying to reproduce & debug the problem with 
the wrong path, after reversing the patch above, and couldn't for the 
life of me make it happen any more.

Going back to an earlier version, I see now that you've made some other 
changes to TestRun to add some "no_chdir => 1" args to the finddepth() 
calls.  Presumably the problem was, as you'd previously suggested, that 
I had Ctrl+C'ed while a finddepth() was in progress and the current 
directory had been changed.  Stopping the chdir's during the finddepth() 
call seems to have fixed it, unless I've just been incredibly lucky 
dozens of times on the trot.

(I wish I'd read the Changes file more carefully -- you did mention the 
no chdir change, but only as a "speedup", so I didn't take it in properly!)
Cool, so I have fixed the problem as a side-effect of the speedup ;)

But really, that's not the case. In addition to using no_chdir, I'm not not 
using File::Find in the score can but only check the t/ directory without 
descending into sub-dirs. But may revert this later. The core file generated 
by httpd will be dropped only in t/ since that's the server root. Though if 
any of the .t tests dumping core and happen to chdir out of t/ the core might 
end up in a different location. Time will show.

So all in all, the current CVS (with the above patch in it) works a 
treat for me.

I think we've got there at last!
Great!

I'm still very unhappy with the way Ctrl-C works (it wrecks havoc on SMOKE 
running on unix), but I'll tend to it some time later. At least we have a 
working version for now.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: modperl-2.0 STATUS

How do you make something a 'private resource' in META.yml?

http://module-build.sourceforge.net/META-spec.html doesn't have
anything about it? Or am I looking at the wrong place?

On Tue, 2003-10-21 at 11:03, [EMAIL PROTECTED] wrote:
> stas2003/10/21 11:03:31
> 
>   Modified:.STATUS
>   Log:
>   META.yml todo issues
>   
>   Revision  ChangesPath
>   1.69  +6 -1  modperl-2.0/STATUS
>   
>   Index: STATUS
>   ===
>   RCS file: /home/cvs/modperl-2.0/STATUS,v
>   retrieving revision 1.68
>   retrieving revision 1.69
>   diff -u -u -r1.68 -r1.69
>   --- STATUS  20 Oct 2003 17:44:48 -  1.68
>   +++ STATUS  21 Oct 2003 18:03:31 -  1.69
>   @@ -90,6 +90,11 @@
>Needs Patch or Further Investigation:
>-
>
>   +* META.yml. Generate META.yml (make dist does that), add Apache-Test
>   +  as a private resource, so it won't be attempted to be indexed by
>   +  PAUSE, add NO_META=>1 to WriteMakefile() which tells EU::MM not to
>   +  overwrite META.yml.
>   +
>*  sections:
>  A few issues with  sections:
>  http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106074969831522&w=2
>   
>   
>   
-- 

Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'


signature.asc
Description: This is a digitally signed message part

Re: cvs commit: modperl-2.0 STATUS

Philippe M. Chiasson wrote:
How do you make something a 'private resource' in META.yml?

http://module-build.sourceforge.net/META-spec.html doesn't have
anything about it? Or am I looking at the wrong place?
It's outdated. See:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00089.html
I don't know what's the right place, I will ask at p5p.

 +* META.yml. Generate META.yml (make dist does that), add Apache-Test
 +  as a private resource, so it won't be attempted to be indexed by
 +  PAUSE, add NO_META=>1 to WriteMakefile() which tells EU::MM not to
 +  overwrite META.yml.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE : Namespace for 3rd party general-purpose mp2 modules



 [Ayhan] The reason I thought it wouldn't be good is that :
1) The mod_perl standard distribution comes under "Apache::" and it
might be useful to distinguish what is "standard" and what is 3rd party,
but if mp2-dev doesn't have any problems with that, then it's OK.
What if we the distro decides to adopt some 3rd party modules into the 
core, like we did with Apache::Reload?


You do have a point there, Stas.

On the other hand, the perl standard distribution can be taken as an 
example. Normally, the p5p development is mainly concerned with the perl 
binary, "CORE::", "B::", "IO::", and maybe some+.

On top of that, the standard perl distribution includes many other modules 
from their own namespaces, like File::Path,  File::Spec, and Digest::MD5, 
just to mention a few.  It works perfectly well. Here, the standard 
distribution acts like a BUNDLE, that's all.  (I think it may even be 
implemented that way too).

Bundle::ModPerl2 or something like that could do the trick.

Come to think of it, I think my main concern here is _not_ the "3rd versus 
1st party" issue. It's about separating the API related modules from 
handlers.

This is something that has always bothered me in the mp1 world. You never 
knew if "Apache::XYZ" was an API module or a response handler or what. 
Especially for a new-comer, believe me this is very unnerving.

MP2 has, to a certain extent, resolved this with the "ModPerl::" and 
"APR::" namespaces. Thanks a bunch for that.

But the "Apache::" namespace is still quite a mess I must say.

It's quite strange that "Apache::FilterRec" and "Apache::VMonitor" live 
under the same hood.  The first is part of the "kitchen" and the other is a 
response handler that serves up HTML at the end of the day (though it 
probably sweats quite a lot to do so.)

That being said, there is the backward-compatibility issue which would make 
it difficult to make such moves. There must be a lot of modules out there 
which "use" Apache::Request.  So it's probably unthinkable to change 
anything like that.

But when it comes to "Apache::VMonitor" (or any response handler for that 
matter), that's probably not the case. Those are referenced from within 
"httpd.conf", that's all. There might be some very rare cases of 
subclassing, but I bet those would be broken across ports anyway.

I don't think anybody can pass from [apache 1.3 + mp1}  to  [apache 2 + 
mp2] without redoing their "httpd.conf".  As long as the semantics of the 
handler configuration parameters stay in place (which is in a way the "api" 
of a handler), I don't see any problems with changing the module name in 
httpd.conf.

Then again, I am not alone ;)  But here's a suggestion anyway

1) Keep backward-compatible API modules where they were :

like :
Apache::Request , ...
2) Move all handlers meant to be "executed" by modperl to some place else :
ModPerl::Responder::*   (for response handlers only)
ModPerl::Filter::*  (for filter handlers only )
ModPerl::Handler::* (for any other kind of handler, including 
those that hook at multiple phases)

Examples :
ModPerl::Responder::VMonitor
ModPerl::Filter::TemplateWrap
ModPerl::Filter::Snoop
If you don't like ModPerl::, Apache:: could be OK too.

And for very select modules, it should be possible to just subclass them at 
their "historical" name-spaces for backwards compatibility, provided that 
they are able to actually support the old API _and_ are able to run under 
both mp1 && mp2 (preferably by dynamic branching or at worst by

Like :
Apache::VMonitorISA =>ModPerl::Responder::VMonitor
Advertise the long name, keep the other for backwards-compatibility for 
some time to come, like twenty years or so ;)

The only problem here would be those old modules that remain in the 
Apache:: name-space without actually working under mp2. But that should be 
rare, since most of those are response handlers, and the "compat" module 
seems to be doing well.


That's examctly the problem, as CPAN (and PAUSE) have no notion of 
supporting several branches/generations of the module. Unless you ask for 
a specific version number, it'll always fetch the latest one. That's the 
issue I'm trying to resolve with CPAN folks. Once mp2 is released we are 
going to have a lot of complaints of people trying to install mp1 and 
getting mp2 instead


As you said : implementation details don't matter : You can perfectly have 
mp1 and mp2 packaged together and let MakeMaker (or the other thing you're 
using) decide... ;)

Just kidding. But I think it demonstrates how messy these dependency issues 
can get. And sometimes (but not always), it might just be better changing 
the name.

For "mod_perl.so", I really don't see any clean way, apart from CPAN 
handling intricate dependency checks with a min _and_ max version, or some 
kind of 'flavor' category as you say. Or maybe p5p will accept to put the 
httpd flavor into the architecture str

Re: [PATCH mp2] Skip getppid() test on Win32

Randy Kobes wrote:
On Tue, 21 Oct 2003, Stas Bekman wrote:


Steve Hay wrote:

Steve Hay wrote:


The attached patch skips the new getppid() test (perl/api.t) on Win32
since getppid() is unimplemented on this platform!
Weird:

% perldoc -f getppid
=item getppid
Returns the process id of the parent process.

Is it a bug in perl? why a non-portable function lives in perlfunc.pod?


I think the portability issues have been relegated to
perlport.pod, which reports that getppid is indeed
unimplemented on Win32.

Doesn't POSIX.pm provide a similar implementation?


It's also unimplemented under POSIX.pm.
Thank Randy. I've applied Steve's patch. Thanks Steve.

I guess nobody has tried using Apache::VMonitor on win32 then. We need to get 
the pid of the parent process in order to calculate the real mem usage (taking 
the sharing into an account). Doesn't win32 implement shared memory? I suppose 
not, since the is no fork. Am I correct?

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: modperl-2.0 STATUS

Seems people haven't decided between no_index and private:

The latest version of Module::Install's META.yml has this bit:

no_index:
  directory:
- inc
private:
  directory:
- inc

On Tue, 2003-10-21 at 14:32, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > How do you make something a 'private resource' in META.yml?
> > 
> > http://module-build.sourceforge.net/META-spec.html doesn't have
> > anything about it? Or am I looking at the wrong place?
> 
> It's outdated. See:
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00089.html
> 
> I don't know what's the right place, I will ask at p5p.
> 
> >>  +* META.yml. Generate META.yml (make dist does that), add Apache-Test
> >>  +  as a private resource, so it won't be attempted to be indexed by
> >>  +  PAUSE, add NO_META=>1 to WriteMakefile() which tells EU::MM not to
> >>  +  overwrite META.yml.
> 
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
-- 

Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'


signature.asc
Description: This is a digitally signed message part

[Patch] META.yml support

From what I've read on the p5p archives, shouldn't this work like we
want it to?

Index: META.yml
===
RCS file: META.yml
diff -N META.yml
--- /dev/null   1 Jan 1970 00:00:00 -
+++ META.yml21 Oct 2003 23:14:08 -
@@ -0,0 +1,11 @@
+# http://module-build.sourceforge.net/META-spec.html
+#XXX This is a prototype!!!  It will change in the future!!! X#
+name: mod_perl
+version:  1.99_11-dev
+version_from: lib/mod_perl.pm
+installdirs:  site
+requires:
+private:
+directory:
+- Apache::Test
+distribution_type: module
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.125
diff -u -I$Id: -r1.125 Makefile.PL
--- Makefile.PL 21 Sep 2003 03:05:18 -  1.125
+++ Makefile.PL 21 Oct 2003 23:14:08 -
@@ -62,6 +62,7 @@
 ModPerl::BuildMM::WriteMakefile(
 NAME  => 'mod_perl',
 VERSION   => $VERSION,
+NO_META   => 1,
 EXE_FILES => [EMAIL PROTECTED],
 DEFINE=> get_DEFINE(),
 macro => {


On Tue, 2003-10-21 at 15:57, Philippe M. Chiasson wrote:
> Seems people haven't decided between no_index and private:
> 
> The latest version of Module::Install's META.yml has this bit:
> 
> no_index:
>   directory:
> - inc
> private:
>   directory:
> - inc
> 
> On Tue, 2003-10-21 at 14:32, Stas Bekman wrote:
> > Philippe M. Chiasson wrote:
> > > How do you make something a 'private resource' in META.yml?
> > > 
> > > http://module-build.sourceforge.net/META-spec.html doesn't have
> > > anything about it? Or am I looking at the wrong place?
> > 
> > It's outdated. See:
> > http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00089.html
> > 
> > I don't know what's the right place, I will ask at p5p.
> > 
> > >>  +* META.yml. Generate META.yml (make dist does that), add Apache-Test
> > >>  +  as a private resource, so it won't be attempted to be indexed by
> > >>  +  PAUSE, add NO_META=>1 to WriteMakefile() which tells EU::MM not to
> > >>  +  overwrite META.yml.
> > 
> > __
> > Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> > http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> > http://modperlbook.org http://apache.org   http://ticketmaster.com
-- 

Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'


signature.asc
Description: This is a digitally signed message part

[Patch mp2] Autogeneration of MANIFEST.SKIP

Since MANIFEST is automatically generated, shouldn't we take that
opportunity to generate MANIFEST.SKIP as well? 

? lib/C
? lib/threads
Index: lib/ModPerl/Manifest.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Manifest.pm,v
retrieving revision 1.7
diff -u -I$Id: -r1.7 Manifest.pm
--- lib/ModPerl/Manifest.pm 26 Sep 2003 17:37:33 -  1.7
+++ lib/ModPerl/Manifest.pm 21 Oct 2003 23:15:09 -
@@ -49,16 +49,31 @@
 my $matches = maniskip();
 open my $fh, '>', 'MANIFEST' or die "open MANIFEST: $!";
 
+my %files;
+
 for my $file (sort @files) {
 if ($matches->($file)) {
 warn "skipping $file\n";
 next;
 }
-
+$files{$file}++;
 print "$file\n";
 print $fh "$file\n";
 }
 
+close $fh;
+
+open $fh, '>', 'MANIFEST.SKIP' or die "open MANIFEST.SKIP: $!";
+my $cwd = Cwd::cwd();
+finddepth({ follow => 1, wanted => sub {
+return if -d;
+my $file = $File::Find::name;
+$file =~ s,^$cwd/?,,;
+unless (exists $files{$file}) {
+print $fh "$file\n";
+}
+}},  Cwd::cwd());
+
 close $fh;
 }
 


-- 

Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'


signature.asc
Description: This is a digitally signed message part

Re: cvs commit: modperl-2.0 STATUS

Philippe M. Chiasson wrote:
Seems people haven't decided between no_index and private:

The latest version of Module::Install's META.yml has this bit:

no_index:
  directory:
- inc
private:
  directory:
- inc
Please mention that in the thread I've just started on p5p. Thanks.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Patch] META.yml support

Philippe M. Chiasson wrote:
From what I've read on the p5p archives, shouldn't this work like we
want it to?
Index: META.yml
===
RCS file: META.yml
diff -N META.yml
--- /dev/null   1 Jan 1970 00:00:00 -
+++ META.yml21 Oct 2003 23:14:08 -
@@ -0,0 +1,11 @@
+# http://module-build.sourceforge.net/META-spec.html
+#XXX This is a prototype!!!  It will change in the future!!! X#
+name: mod_perl
+version:  1.99_11-dev
eh, that's not fun. hardcoded version number? what's version_from in then for?

+version_from: lib/mod_perl.pm
+installdirs:  site
+requires:
+private:
+directory:
+- Apache::Test
that should be Apache-Test

+distribution_type: module
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.125
diff -u -I$Id: -r1.125 Makefile.PL
--- Makefile.PL 21 Sep 2003 03:05:18 -  1.125
+++ Makefile.PL 21 Oct 2003 23:14:08 -
@@ -62,6 +62,7 @@
 ModPerl::BuildMM::WriteMakefile(
 NAME  => 'mod_perl',
 VERSION   => $VERSION,
+NO_META   => 1,
 EXE_FILES => [EMAIL PROTECTED],
 DEFINE=> get_DEFINE(),
 macro => {
the rest looks good.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Patch mp2] Autogeneration of MANIFEST.SKIP

Philippe M. Chiasson wrote:
Since MANIFEST is automatically generated, shouldn't we take that
opportunity to generate MANIFEST.SKIP as well? 
what do we need it for?

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE : [PATCH] add PERL5LIB to @INC in the correct order

Guilty as charged, but I said that in first place ;)
... snip ...
Therefore please bear with me and feel free to nudge me if my
in-head-filter has ignored your email, just like you did now ;)

Don't worry Stas, and thanks for bearing with me bombarding you with lots
of babble.
Besides, this is not an urgent topic for me, so please feel free to let it
sleep for a while...

But please do me a favour and read it. -- it's attached.
I did now, and you bring points that Geoff has already mentioned: PERL5LIB
setting per-dir doesn't work in mp1, so it won't work under mp2.
Don't understand the 'so' connector here. Are you suggesting that there may
be "httpd.conf" files out there today which do set PERL5LIB (of all
things) in a directory section without the actual intention of that having
any effect, so that they would suddenly break upon upgrading to mp2
??? --especially if the behavior is governed by a switch (like
SetupPERL5LIB ) as suggested earlier, I would rather think that is unlikely.

The solution is simple - don't use PERL5LIB, use PerlSwitches as I've
documented here:
http://perl.apache.org/docs/2.0/user/config/config.html#Adjusting_C__INC_
http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost

So the Vhost solution perfectly answers your problem with setting up a
different @INC, for different setups running on the same server.

That's what I have been doing, and willing to do as a work-around until I
convince you to put in the feature ;) or until I end up hacking something
on my own.
Cause what I need is really per-dir. There's no hurry though

Another crafty solution would be to use PerlInitHandler to push some libs
onto @INC and PerlCleanupHandler to pop them away. Apache::PerlVINC in mp1
does exactly that. Feel free to port it to mp2 / talk to the author first?
http://search.cpan.org/~davem/Apache-PerlVINC-0.03/PerlVINC.pm

It might perhaps be an option, but only if I can manage to extend it so
that it can optionally use PERL5LIB instead of a fixed set of directories.
But for that, the environment needs to have been set up already, I am not
sure it is at the PerlInitHandler phase. Need to check it out;

In any case, I am thinking more and more that this "feature" may belong to
ModPerl::RegistryCooker at the end of the day and not to mod_perl
itself, since the divergence is with regard to mod_cgi.
For a CGI, one expects PERL5LIB to work the same way as under mod_cgi. A
"pure" perl handler, on the other hand, knows that it lives in a persistent
interpreter which naturally processes its PERL5LIB at start-up time.

Given that, how about if I submitted a patch to RegisteryCooker, which
already mingles with INC in its "run" method. Subclassing could also be an
option for some time (until you are convinced), overriding the "run" method.

Below is my poor man's use-case that has motivated me for all this :

I love it when an application works both under mod_cgi and mod_perl. Call
me a maniac (but I am not alone). I allow myself (and the rest of the poor
team here) to use mod_perl & apache specific features _only_ for
non-response handlers (filters & such)Except on extremely rare
occasions, anything that generates a response is written to be a plain CGI
script without any global variables (so that they will work under
mod-perl). The CGI script will handle anything that is "web-related"
(relying on CGI.pm and TT). All "business logic", as they call it, is done
in specialized modules who know nothing about the web or HTML or anything.

Yes, this may be keeping us from unleashing the full power of mp, but it
also keeps us from other headaches, especially while mp is going thru change.

Throughout the development phase, we test under both mod_cgi and mod_perl,
switching between them frequently (actually this is also quite useful for
testing parts of mp2, as it lets you see where it diverges. Another
advantage is to actually experience --and appreciate over and over again--
the performance gains that mod_perl brings. Add to that some CGI::Cache,
and some "memoize" & singleton magic which really comes to life only under
mod-perl, you're set for a pleasant ride...)

Under mod_cgi, we have to use PERL5LIB; for mod_perl PerlVINC
force(s/d) you to use some other "api". Ain't good.

So I am a lazy dude who likes to blindly switch between mod_cgi and
mod_perl with less then 10 key-strokes. And that's why I have been typing
several thousand key-strokes for this thread ;)

Cheers,

Ayhan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: porting Sandwich to mp2