Joe Schaefer wrote:
> I really
> see this as reducing user complaints; after all, httpd's
> "Options" are case-insensitive as well.
I'm tempted to agree with this pov.
if performance is really an issue, we could just make case-sensitivity a
compile time option, enabling case-insensitive direct
Pratik wrote:
I would like to support Randal's contention (if not his tone) that
indeed, in real-world mod_perl commercial situations that I'm familiar
with (say about 8), 80% of those real-world users will want to have both
mod_perl 1 and mod_perl 2 installed concurrently due to the
generally-acce
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
-0:
while it's fine for startup code, it'll affect
modperl_config_is_perl_option_enabled, that may be called at request
time == slowdown.
Are the option strings in German or something? It can't
be a measurable performance differenc
Gisle Aas wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Gisle Aas wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
I've played with it some more. The following program demonstrates some
So again perl doesn't provide enough public API to properly juggle
perl interpreters.
I disagree. The API seems
Stas Bekman <[EMAIL PROTECTED]> writes:
> Gisle Aas wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> >
> >>I've played with it some more. The following program demonstrates some
> >>So again perl doesn't provide enough public API to properly juggle
> >>perl interpreters.
> > I disagree. The A
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> -0:
>
> while it's fine for startup code, it'll affect
> modperl_config_is_perl_option_enabled, that may be called at request
> time == slowdown.
Are the option strings in German or something? It can't
be a measurable performance difference to d
Philippe M. Chiasson wrote:
Currently, PerlOptions takes case-sensitive options, (e.g. RegisterGlobal)
and any change in capitalization will not be recognized as a valid option.
Suggested patch makes it case-insensitive.
Index: lib/ModPerl/Code.pm
===
On Mon, 10 Jan 2005, Joe Schaefer wrote:
> "Philippe M. Chiasson" <[EMAIL PROTECTED]> writes:
>
> > Currently, PerlOptions takes case-sensitive options, (e.g. RegisterGlobal)
> > and any change in capitalization will not be recognized as a valid option.
> >
> > Suggested patch makes it case-insens
"Philippe M. Chiasson" <[EMAIL PROTECTED]> writes:
> Currently, PerlOptions takes case-sensitive options, (e.g. RegisterGlobal)
> and any change in capitalization will not be recognized as a valid option.
>
> Suggested patch makes it case-insensitive.
+1 to case-insensitive options.
--
Joe Scha
Currently, PerlOptions takes case-sensitive options, (e.g. RegisterGlobal)
and any change in capitalization will not be recognized as a valid option.
Suggested patch makes it case-insensitive.
Index: lib/ModPerl/Code.pm
===
--- lib/Mod
Gisle Aas wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
I've played with it some more. The following program demonstrates some
So again perl doesn't provide enough public API to properly juggle
perl interpreters.
I disagree. The API seems fine to me.
No.
1) There is a bug in perl_alloc. As my p
Geoffrey Young wrote:
$Listen = 44901;
$Listen = 44901;
this isn't a mod_perl problem - if I take the default httpd.conf from an
apache 2.0 installation and just copy the default Listen line to
Listen 80
Listen 80
I get the same error message.
Absolutely correct Geoff. Pratik, sections ju
Stas Bekman <[EMAIL PROTECTED]> writes:
> I've played with it some more. The following program demonstrates some
> So again perl doesn't provide enough public API to properly juggle
> perl interpreters.
I disagree. The API seems fine to me.
> Suggestions?
Don't mess with PL_curintep or FREE_TH
I've played with it some more. The following program demonstrates some of
the problems I've discovered. Notice that on my OS the limit for thread
keys is 1024.
/* destruct.c */
#include
#include
/*
* gcc -o destruct destruct.c `perl-5.8.6-ithread -MExtUtils::Embed -e
ccopts -e ldopts` -Wall
Yep, they would.
Unless the structural indexer was capable of understanding that...
But in general, yes.
Adam
Eric Cholet wrote:
Le 9 janv. 05, à 13:14, Adam Kennedy a écrit :
[...]
Now the problem with multi-API situations is likely to be that under
normal situations, if some PPI-based software e
Le 9 janv. 05, à 13:14, Adam Kennedy a écrit :
[...]
Now the problem with multi-API situations is likely to be that under
normal situations, if some PPI-based software encounters
Apache::Something->method it would normally interpret it as a method
call in the "most current" version of the Apache
16 matches
Mail list logo
