> Sounds good to me, but I have a question. If one does :
>
>
> PerlSetINC /this/dir
>
>
>
> PerlSetINC /this/other/dir
>
>
> Can I assume that it would:
>
> 1. Populate @INC on a per-request/per-location basis ?
> 2. Allow for changes of @INC , like if the application code fiddles
On Tue, Nov 20, 2001 at 02:22:54PM +0800, Stas Bekman wrote:
> Doug MacEachern wrote:
>
> >On Mon, 12 Nov 2001, Stas Bekman wrote:
> >
> >
> >>this patch implements the PerlINC wrapper which does:
> >>s/PerlSwitches -Ilib=foo/PerlINC foo/
> >>
> >
> >if we add a new directive like this i think it
Doug MacEachern wrote:
> On Mon, 12 Nov 2001, Stas Bekman wrote:
>
>
>>this patch implements the PerlINC wrapper which does:
>>s/PerlSwitches -Ilib=foo/PerlINC foo/
>>
>
> if we add a new directive like this i think it should be a wrapper around
> what 'Perl{Set,Pass}Env PERL5LIB' would do, th
Gerald Richter wrote:
>>can you run: t/TEST -v t/modules/cgi
>
> A whole make test fails, but testing cgi alone works:
which means that some other test running earlier changes the state of
the server and doesn't restore it. if you run tests -mode=random
-times=5 or similar you will probably s
Doug MacEachern wrote:
> ok, its the mixing of Add and Set directives that i was missing. i agree
> something needs to be fixed, but i don't think 2.0 is fixing it the
> right way. the main problem i have is that current 2.0 breaks this:
>
> Add A 1
>
>
> Add A 2
>
>
> inside foo, 1.x
ok, its the mixing of Add and Set directives that i was missing. i agree
something needs to be fixed, but i don't think 2.0 is fixing it the
right way. the main problem i have is that current 2.0 breaks this:
Add A 1
Add A 2
inside foo, 1.x would get both 1 and 2, 2.0 only gets 2. that
>
> can you run: t/TEST -v t/modules/cgi
>
A whole make test fails, but testing cgi alone works:
...
modperl/readlineok
modperl/sameinterp..ok
modules/cgi.FAILED test 3
Failed 1/6 tests, 83.33% okay
modules/cgiupload...ok
protocol/echo...ok
protocol/echo_filter.ok
protoco
Doug MacEachern wrote:
> On Tue, 20 Nov 2001, Stas Bekman wrote:
>
>
>>which as we have discussed is not what we want, since we don't want all
>>the data from the two. The overlay structure should override the base
>>structure if the same key exists in both. I guess I should put a better
>>
On Tue, 20 Nov 2001, Stas Bekman wrote:
> which as we have discussed is not what we want, since we don't want all
> the data from the two. The overlay structure should override the base
> structure if the same key exists in both. I guess I should put a better
> comment in place.
ok, remind m
Doug MacEachern wrote:
> On Tue, 20 Nov 2001, Stas Bekman wrote:
>
>
>>exactly for the same reason that addn() should be used.
>>apr_table_overlay uses setn() which will loose all pairs with the same
>>key but the last one added.
>>
>>apr_table_overlay:
>> * for (i = 0; i < barr->nelts; +
On Tue, 20 Nov 2001, Stas Bekman wrote:
> exactly for the same reason that addn() should be used.
> apr_table_overlay uses setn() which will loose all pairs with the same
> key but the last one added.
>
> apr_table_overlay:
> * for (i = 0; i < barr->nelts; ++i) {
> * if (flags & AP
Doug MacEachern wrote:
> On Mon, 19 Nov 2001, Stas Bekman wrote:
>
>
>>yes, that's a bug, must be addn()
>>
>
> remind me why we don't just use apr_table_overlay like 1.x does for SetVar?
exactly for the same reason that addn() should be used.
apr_table_overlay uses setn() which will loose
On Mon, 19 Nov 2001, Stas Bekman wrote:
> yes, that's a bug, must be addn()
remind me why we don't just use apr_table_overlay like 1.x does for SetVar?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-m
On Tue, 20 Nov 2001, Stas Bekman wrote:
> I prefer t_debug(), ok? don't want people to start using t_print("ok 5").
that's fine. and maybe it could do more than 'print' would. like how
TestTrace does the expand() with Data::Dumper, rather than have another
function for t_dumper().
On Tue, 20 Nov 2001, Stas Bekman wrote:
> would it be better if it was clear from name that it's a constant? e.g.
> Apache::ServerRoot or Apache::SERVER_ROOT. I suppose that since it's a
> sub anyway, Apache::server_root() will work too.
i think its better to keep it as the same name as apach
Doug MacEachern wrote:
>>probably should add something like that:
>>
>>Apache::TestUtil:
>>sub t_print_debug { print map {"# $_\n"} map {split /\n/} @_ };
>>
>
> nice. naming it t_print() would be fine too.
I prefer t_debug(), ok? don't want people to start using t_print("ok 5").
___
[EMAIL PROTECTED] wrote:
> dougm 01/11/19 15:46:48
>
> Modified:xs/Apache/ServerUtil Apache__ServerUtil.h
>xs/maps apache_functions.map
> Log:
> add Apache::server_root constant
would it be better if it was clear from name that it's a constant? e.g.
Apache::Se
Apache::server_root_relative is now fully 1.x compat and there is
a new Apache::server_root constant (no trailing /).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Mon, 19 Nov 2001, Gerald Richter wrote:
> One of the cgi tests also fails always for mod_perl 1.x on that machine and
> we never found out why. So maybe it's the same reason here ?
could be the file upload test.
> In the error log I don't see anything what's wrong, but maybe I have
> overs
>
> sorry, stas pointed out, i forgot to commit a file.
No problem
> can you try again
> now?
>
Looks much better. Now only one test fails:
Failed Test Status Wstat Total Fail Failed List of Failed
modules/cgi
On Mon, 19 Nov 2001, Gerald Richter wrote:
> Hi,
>
> after haveing to work on other projects inbetween, I am back to mod_perl
> development, especially I want to finish the xs building stuff, to get it
> reincorporated into mod_perl.
>
> To make sure my xs building stuff is doing the right thin
On Mon, 19 Nov 2001, Stas Bekman wrote:
> We should try not to print debug stuff without prefixing each line with
> # (at least for the new tests that we write). Otherwise it may mess up
> Test::Harness (according to its docs).
right. i actually meant to take those out before committing.
>
Hi,
after haveing to work on other projects inbetween, I am back to mod_perl
development, especially I want to finish the xs building stuff, to get it
reincorporated into mod_perl.
To make sure my xs building stuff is doing the right thing, I want to have a
running make test first, so I can veri
23 matches
Mail list logo
