Jie Gao wrote:
Hi Stas,
perl-5.8.3_threaded + Latest cvs + apache_2.0.49
make test fails with the error:
[warning] testing whether 'nobody' is able to -rwx /u0/local/src/modperl-2.0/t
"/usr/local/perl-5.8.3_threaded/bin/perl"
-Mlib=/u0/local/sr
Hi Stas,
perl-5.8.3_threaded + Latest cvs + apache_2.0.49
make test fails with the error:
[warning] testing whether 'nobody' is able to -rwx /u0/local/src/modperl-2.0/t
"/usr/local/perl-5.8.3_threaded/bin/perl"
-Mlib=/u0/local/src/modperl-2.
Geoffrey Young wrote:
Stas Bekman wrote:
The Apache docs say not to access directly $c->remote_host() but always
call $c->get_remote_host. I see that mp1 had both with the suggestion
not to use $c->remote_host(). I suggest that we drop $c->remote_host()
but it's somewhat related to the earlier sugg
Geoffrey Young wrote:
So what should we do about it?
I suppose we could make it get/set at startup time
perhaps, but most people have asked for writability at request time, not
startup time.
and get/set at all
times for non-threaded mpms and only get for threaded mpms, like we did
with a few oth
Stas Bekman wrote:
> The Apache docs say not to access directly $c->remote_host() but always
> call $c->get_remote_host. I see that mp1 had both with the suggestion
> not to use $c->remote_host(). I suggest that we drop $c->remote_host()
> but it's somewhat related to the earlier suggestion to ma
> So what should we do about it?
>
> I suppose we could make it get/set at startup time
perhaps, but most people have asked for writability at request time, not
startup time.
> and get/set at all
> times for non-threaded mpms and only get for threaded mpms, like we did
> with a few other struc
[EMAIL PROTECTED] wrote:
> gozer 2004/08/17 15:51:24
>
> Modified:.Changes
>xs/maps apache_functions.map apache_structures.map
> Log:
> Apache::Module changes
> - readwrite => readonly:
> cmds, next, name, module_index, minor_version, version
+1
At the moment $r->document_root is a 1:1 mapping to ap_document_root,
which only gives you the value, and doesn't allow you to set it.
As Dave (CC'ed) pointed out, some people already want to use it as they
did in mp1, i.e. set it to some value.
The problem of allowing the setting of doc_root (
The Apache docs say not to access directly $c->remote_host() but always
call $c->get_remote_host. I see that mp1 had both with the suggestion not
to use $c->remote_host(). I suggest that we drop $c->remote_host()
but it's somewhat related to the earlier suggestion to make
$c->remote_host settabl
Steve Hay wrote:
This allows the test to run successfully in isolation for me, but "nmake
test" now hangs when it reaches this test.
great!
Even reverting this change I still find that "nmake test" hangs when it
gets to that test. Must be something else that's changed since Friday...
Yes, this c
Stas Bekman wrote:
>Markus Wichitill wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>>Index: t/filter/TestFilter/out_bbs_filebucket.pm
>>>===
>>>RCS file:
>>>/home/cvs/modperl-2.0/t/filter/TestFilter/out_bbs_filebucket.pm,v
>>>retri
Steve Hay wrote:
t\filter\in_bbs_inject_header.t always succeeds when run as part of
the whole "nmake new" run, and only sometimes crashes Apache when run
alone, which was only uncovered by last night's SMOKE run.
After numerous attempts, mine finally failed (running in isolation)
too.
You me
Stas Bekman wrote:
>Markus Wichitill wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
t\filter\in_bbs_inject_header.t always succeeds when run as part of
the whole "nmake new" run, and only sometimes crashes Apache when run
alone, which was only uncovered by last night's SMOKE run.
>>>
Stas Bekman wrote:
Philippe M. Chiasson wrote:
For nothing, really. I must apologize for the confusion. I started
trying to get ->limited to work, and for that, I needed to open
up Apache::MethodList.
:)
I abandonned that effort too late for a simpler implementation of
ap_method_is_limited().
A
Philippe M. Chiasson wrote:
For nothing, really. I must apologize for the confusion. I started
trying to get ->limited to work, and for that, I needed to open
up Apache::MethodList.
:)
I abandonned that effort too late for a simpler implementation of
ap_method_is_limited().
Attached are the 2 patch
So, do we have any showstoppers for 1.99_15 release? Should some tests be
excluded from the distro?
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apach
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
[...]
+For example, to check if the C method is being ELimitEed
+in the current scope, do:
+
+ if ($parms->method_is_limited('GET') {
+ die "...";
+ }
For code sections in the docs please always use a prefix of two
Stas Bekman wrote:
Philippe M. Chiasson wrote:
In trying to make sense of Apache::CmdParms->limited() I realized it was
mainly useless to expose, and that there was a method
ap_method_is_limited()
designed for that exact purpose.
So the following patch removed the parms->limited field and replac
Stas Bekman wrote:
Philippe M. Chiasson wrote:
remove_module() and remove_loaded_module() are currently exposed thru
Apache::Module
and I am wondering if that is a good idea. Those methods allow the
removing of arbitrary
httpd modules. The functions add_module() and add_loaded_module() are
alr
Stas Bekman wrote:
Philippe M. Chiasson wrote:
The following ap_module_t fields are currently writable, and I can't
think of a
good reason why they should be. As I am trying to finish the
documentation for
Apache::Module, I'd like to suggest making the following fields read-only:
version
minor_
Philippe M. Chiasson wrote:
[...]
+For example, to check if the C method is being ELimitEed
+in the current scope, do:
+
+ if ($parms->method_is_limited('GET') {
+ die "...";
+ }
For code sections in the docs please always use a prefix of two spaces. So
it's easy to move code from docs to r
Philippe M. Chiasson wrote:
In trying to make sense of Apache::CmdParms->limited() I realized it was
mainly useless to expose, and that there was a method
ap_method_is_limited()
designed for that exact purpose.
So the following patch removed the parms->limited field and replaces it
with ap_method
Philippe M. Chiasson wrote:
The following ap_module_t fields are currently writable, and I can't
think of a
good reason why they should be. As I am trying to finish the
documentation for
Apache::Module, I'd like to suggest making the following fields read-only:
version
minor_version
module_index
Philippe M. Chiasson wrote:
remove_module() and remove_loaded_module() are currently exposed thru
Apache::Module
and I am wondering if that is a good idea. Those methods allow the
removing of arbitrary
httpd modules. The functions add_module() and add_loaded_module() are
already not available,
remove_module() and remove_loaded_module() are currently exposed thru Apache::Module
and I am wondering if that is a good idea. Those methods allow the removing of
arbitrary
httpd modules. The functions add_module() and add_loaded_module() are already not
available,
so unless we keep all four, I
The following ap_module_t fields are currently writable, and I can't think of a
good reason why they should be. As I am trying to finish the documentation for
Apache::Module, I'd like to suggest making the following fields read-only:
version
minor_version
module_index
name
next
cmds
Patch below.
In
Philippe M. Chiasson wrote:
> In trying to make sense of Apache::CmdParms->limited() I realized it was
> mainly useless to expose, and that there was a method
> ap_method_is_limited()
> designed for that exact purpose.
>
> So the following patch removed the parms->limited field and replaces it
>
Randy Kobes wrote:
I'll take a look at this when I get back too, just to
compare ... I think you mentioned this earlier, but
just to confirm - everything (Perl, Apache, mod_perl) was
compiled with VS7? I've heard of problems trying to
mix stuff compiled with VS7 and VC++ 6 (which is
what the Apache
On Tue, 17 Aug 2004, Markus Wichitill wrote:
> Randy Kobes wrote:
> >>>Crashes on t\manip\out_append.t #1, with no useful error_log either.
> > Is this a crash, in the sense that a pop-up window
> > appears with a message about, eg, an access violation?
>
> It's a "The command in 0x12345678 points
Randy Kobes wrote:
Crashes on t\manip\out_append.t #1, with no useful error_log either.
Is this a crash, in the sense that a pop-up window
appears with a message about, eg, an access violation?
It's a "The command in 0x12345678 points to memory in 0x12345678. The action
'read' couldn't be performe
On Sun, 15 Aug 2004, Stas Bekman wrote:
> Markus Wichitill wrote:
> > Stas Bekman wrote:
> >
> >>> t\filter\in_bbs_inject_header.t always succeeds when run as part of
> >>> the whole "nmake new" run, and only sometimes crashes Apache when run
> >>> alone, which was only uncovered by last night's S
31 matches
Mail list logo
