I think I've cleaned up all my previous mp2 cvs checkouts, unless someone
else needs a running cvs (to diff the old checkouts), we should ask to
disable cvs for modperl-2.0 and modperl-docs so users won't try to update
an outdated repository.
--
_
I'm cleaning up my old cvs checkouts so we can nuke the cvs support and
not confuse users. I've found this semi-complete $r->content
implementation. All it does is slurping the body instead of doing all that
in perl (if you aren't using CGI.pm or A::R):
sub read_post {
my $r = shift;
my
1) copy environ to %ENV and detach at the very beginning.
now if a vhost with its own interpreter changes %ENV it won't affect the
base server.
Each vhost will be able to have its own sections and/or
PerlRequire, independent from the main server config, right?
Oops, this is a problem. No, only v
On Thu, 16 Dec 2004, Stas Bekman wrote:
> In fact this will do exactly the same:
>
> PerlPassEnv PATH
>
>$ENV{PATH} = $ENV{INSTANCE} eq 'development'
> ? "$ENV{PATH}:/extra/devl/path/needed/by/my/modules"
> : "$ENV{PATH}:/extra/prod/path/nee
Larry Leszczynski wrote:
Hi Stas -
I propose the following "simple" solution:
1) Keep %ENV intact at the server startup, so anything set in the shell is
seen from perl
2) PerlPassEnv and PerlSetEnv aren't run yet but postponed to until after
post_config.
3) just before starting workers, detach %EN
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Here is a new version of my original patch that includes tests (no
doc though)
so when committing please add a least a very basic doc in config.pod so we
can point users to it, and I'll extend those later.
+merge_item
Hi Stas -
> I propose the following "simple" solution:
>
> 1) Keep %ENV intact at the server startup, so anything set in the shell is
> seen from perl
> 2) PerlPassEnv and PerlSetEnv aren't run yet but postponed to until after
> post_config.
> 3) just before starting workers, detach %ENV from envi
Geoffrey Young wrote:
PerlPassEnv HOME
PerlPassEnv PORT
$ServerRoot = $ENV{HOME} . "/web";
$DocumentRoot = $ENV{HOME} . "/web/public" ;
$Listen = $ENV{PORT};
Thanks for the example, Pratik. Now it's more clear to me.
I propose the following "simple" solution:
1) Keep %ENV intact at the server st
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Here is a new version of my original patch that includes tests (no doc
though)
+merge_item(PerlPostConfigRequire);
I was wondering if it makes sense to merge this one.
It's necessary, for the same reason PerlRequire or PerlModule
has to be merged
>> PerlPassEnv HOME
>> PerlPassEnv PORT
>>
>> $ServerRoot = $ENV{HOME} . "/web";
>> $DocumentRoot = $ENV{HOME} . "/web/public" ;
>> $Listen = $ENV{PORT};
>>
>
>
> Thanks for the example, Pratik. Now it's more clear to me.
>
> I propose the following "simple" solution:
>
> 1) Keep %ENV intact
>
> Thanks for the example, Pratik. Now it's more clear to me.
>
> I propose the following "simple" solution:
>
> 1) Keep %ENV intact at the server startup, so anything set in the shell is
> seen from perl
> 2) PerlPassEnv and PerlSetEnv aren't run yet but postponed to until after
> post_config.
Philippe M. Chiasson wrote:
Here is a new version of my original patch that includes tests (no doc
though)
+merge_item(PerlPostConfigRequire);
I was wondering if it makes sense to merge this one.
+
Philippe, mind you not add lines like: /^$/, I have to cleanup those
after every of yo
Markus Wichitill wrote:
Stas Bekman wrote:
Markus Wichitill wrote:
Well, I haven't written any C/C++ in a while and I've never had to
deal with macro hell, but as far as I can see, newSVpvf is defined in
Perl's embed.h:
#define newSVpvfPerl_newSVpvf
If I add that line to the top of ModPe
13 matches
Mail list logo
