whoops, i had modified extra.conf, not extra.conf.in
should be working now.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Doug MacEachern wrote:
> On Tue, 9 Apr 2002, Stas Bekman wrote:
>
>
>>that doesn't solve the problem for those expecting @INC to be
>>un-modified behind the scenes.
>
>
> one of us is missing something.
> my most recent suggestion was to *change* any instance of '.' in @INC to
> cwd, not to
On Tue, 9 Apr 2002, Stas Bekman wrote:
> that doesn't solve the problem for those expecting @INC to be
> un-modified behind the scenes.
one of us is missing something.
my most recent suggestion was to *change* any instance of '.' in @INC to
cwd, not to add anything. so lets say @INC was:
-8<--Start Bug Report 8<--
1. Problem Description:
when running:
t/TEST -v modules/include
I get:
[Tue Apr 09 11:16:54 2002] [error] 3251: ModPerl::Registry: `Can't call
method "args" on an undefined value at
/home/stas/perl/ithread/lib/5.7.3/CGI.pm li
Doug MacEachern wrote:
> On Tue, 9 Apr 2002, Stas Bekman wrote:
>
>
>>I'm not sure that's a good idea. It may break someone's code, who didn't
>>expect the cwd to be in @INC. should the control to automatically
>>prepand to @INC be given to users here?
>
> to be safer, could just replace any
On Tue, 9 Apr 2002, Stas Bekman wrote:
> exit fails here, grabbing the value from the last eval
fixed. modperl_perl_exit now does the same as Perl_pp_entrytry (aka eval {})
before calling Perl_croak
-
To unsubscribe, e-mail:
On Tue, 9 Apr 2002, Stas Bekman wrote:
> I'm not sure that's a good idea. It may break someone's code, who didn't
> expect the cwd to be in @INC. should the control to automatically
> prepand to @INC be given to users here?
to be safer, could just replace any @INC value of '.' with cwd.
> w
Doug MacEachern wrote:
> On Tue, 9 Apr 2002, Stas Bekman wrote:
>
>
>>1. The chdir issue with registry isn't resolved yet, need to do
>>something about it before mod_perl 2.0 will be really useful for people,
>>since want it or not, there are many users who want only the registry
>>interface.
On Tue, 9 Apr 2002, Stas Bekman wrote:
> and if MP_TEST_TRACE is not defined, should it inherit MP_BUILD_TRACE or
> not?
no, should stay the default.
> and an equivalent APACHE_BUILD_TRACE?
no, i meant APACHE_TEST_TRACE to be supported in Apache::TestTrace, not
specific to mod_perl.
exit fails here, grabbing the value from the last eval
Index: t/response/TestModperl/exit.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestModperl/exit.pm,v
retrieving revision 1.1
diff -u -r1.1 exit.pm
--- t/response/TestModper
Doug MacEachern wrote:
> On Tue, 9 Apr 2002, Stas Bekman wrote:
>
>
>>As we move to use Apache::TestTrace for controlled output,
>>I propose a new build flag MP_NOISE flag equivalent to t/TEST's:
>>-trace=T change tracing default to: warning, notice, info,
>>debug, ...
>
>
> +1
On Tue, 9 Apr 2002, Stas Bekman wrote:
> 1. The chdir issue with registry isn't resolved yet, need to do
> something about it before mod_perl 2.0 will be really useful for people,
> since want it or not, there are many users who want only the registry
> interface.
sure, but not everybody usin
On Tue, 9 Apr 2002, Stas Bekman wrote:
> As we move to use Apache::TestTrace for controlled output,
> I propose a new build flag MP_NOISE flag equivalent to t/TEST's:
> -trace=T change tracing default to: warning, notice, info,
> debug, ...
+1 or:
MP_TRACE - what it already is
MP_
>>While debugging the problem, I've noticed that if the Makefile.PL in
>>sub-dirs fails, it's silently swallowed. I think it should croak. Is it
>>a problem with MakeMaker in general or something specific to
>>modperl-2.0/Makefile.PL? Most likely the former.
>
>
> this would be a MakeMaker i
On Tue, 9 Apr 2002, Issac Goldstand wrote:
> I don't know if my vote counts, but...
> -1 to turning off colors.
actually, we don't really vote in modperl land. '+1' just means "yeah, i
agree, go for it". there is no such thing as '-1' in modperl land.
as for the colors, changing the variable
On Mon, 8 Apr 2002, Stas Bekman wrote:
> David Harris has suggested to log all the build errors/warnings into a
> file BUILD_ERRORS, so if users have a problem the SUPPORT doc will first
> ask them to check if they have any errors in this file. This should
> somewhat shorten the number of emai
On Mon, 8 Apr 2002, Stas Bekman wrote:
> ok, the patch at the end solves the problem. Now any sub-dir can enjoy
> from imported My::test, etc.
looks right to me, +1
> While debugging the problem, I've noticed that if the Makefile.PL in
> sub-dirs fails, it's silently swallowed. I think it sh
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> Doug MacEachern wrote:
>>
>>> hopefully today. i'm doing some more testing, there's a snapshot
>>> here if
>>> anybody wants to test:
>>> http://perl.apache.org/~dougm/mod_perl-1.99_01-dev.tar.gz
>>>
>>> please report test results and perl -V if y
1. The chdir issue with registry isn't resolved yet, need to do
something about it before mod_perl 2.0 will be really useful for people,
since want it or not, there are many users who want only the registry
interface.
2. should we revert back to Apache::Registry from ModPerl::Registry, now
th
As we move to use Apache::TestTrace for controlled output,
I propose a new build flag MP_NOISE flag equivalent to t/TEST's:
-trace=T change tracing default to: warning, notice, info,
debug, ...
though MP_TRACE is taken already.
So by default we will have this set to 'warning' and l
On Sun, 7 Apr 2002, Stas Bekman wrote:
> you suggested to make these non-todo for perl > 5.7.3, which I did.
> with 5.6.1 it's broken and randomly passes sub-tests.
ok.
> The only way to remove these messages is to skip the test completely for
> perl < 5.7.3.
that's be very nice.
Issac Goldstand wrote:
> I don't know if my vote counts, but...
> -1 to turning off colors.
> I was delighted to see them - it made more critical points during the
> build/test process much easier to catch as they went by. I'm not saying
> that we can't look into improving them somehow (either
I don't know if my vote counts, but...
-1 to turning off colors.
I was delighted to see them - it made more critical points during the
build/test process much easier to catch as they went by. I'm not saying
that we can't look into improving them somehow (either better
combinations or trying to
+1 on turning color off by default. that'd mean changing
APACHE_TEST_NO_COLOR to APACHE_TEST_COLOR, enabling colors if
$ENV{APACHE_TEST_COLOR}.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EM
David Harris has suggested to log all the build errors/warnings into a
file BUILD_ERRORS, so if users have a problem the SUPPORT doc will first
ask them to check if they have any errors in this file. This should
somewhat shorten the number of emails before a user in trouble realizes
that she n
As reported by John Siracusa certain colors that we use make the
messages almost unreadable on certain terms. I don't think we can come
up with a color map working for everybody and we will end up having more
complaints than we have added value from the colors.
On the other hand, as a develope
Geoffrey Young wrote:
> Doug MacEachern wrote:
>
>>hopefully today. i'm doing some more testing, there's a snapshot here if
>>anybody wants to test:
>>http://perl.apache.org/~dougm/mod_perl-1.99_01-dev.tar.gz
>>
>>please report test results and perl -V if you have a chance. thanks.
>
>
> I am
Doug MacEachern wrote:
>
> hopefully today. i'm doing some more testing, there's a snapshot here if
> anybody wants to test:
> http://perl.apache.org/~dougm/mod_perl-1.99_01-dev.tar.gz
>
> please report test results and perl -V if you have a chance. thanks.
I am having trouble with current CV
28 matches
Mail list logo
