[mp2 filters] allocating modperl_wbucket_t or not
Currently we allocate a wbucket of type modperl_wbucket_t for each
filter invocation. If it's not a streaming filter (i.e. manipulates
bucket brigades or doesn't use read/print) it's never going to need
wbucket. wbucket consumes 16404 bytes, the filter struct without
wbucket consumes 60 bytes. In order not to penalize non-streaming
filters, I suggest not to allocate wbucket if and not until it's first
used.
So we save a lot of wasteful memory allocations if streaming API is
not used (allocating 60 bytes instead of 16464). If the streaming API
is used we pay with if(!wb) conditional for each
$f->print and $f->flush calls, since there is no special entry point
for streaming filters (a filter can be anything).
Here is the patch. Notice that you have to rebuild from scratch if you
test it, since sources under xs/ have a broken dependency on header
files under src/, therefore they won't see the change in the size of
modperl_filter_t and you will get all kind of weird segfaults (I spent
quite some time trying to understand what's going on until it hit me
and I'd rebuilt from scratch).
Index: src/modules/perl/modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.77
diff -u -r1.77 modperl_filter.c
--- src/modules/perl/modperl_filter.c 11 Dec 2003 07:38:41 - 1.77
+++ src/modules/perl/modperl_filter.c 11 Dec 2003 09:20:45 -
@@ -20,6 +20,19 @@
#define MP_FILTER_POOL(f) f->r ? f->r->pool : f->c->pool
+/* allocate wbucket memory using malloc and not request pools, since
+ * we may need many of these if the filter is invoked multiple
+ * times */
+#define WBUCKET_INIT(wb, p, next_filter) \
+if (!wb) { \
+wb = (modperl_wbucket_t *)safemalloc(sizeof(*wb)); \
+wb->pool= p; \
+wb->filters = &next_filter;\
+wb->outcnt = 0; \
+wb->r = NULL;\
+wb->header_parse = 0; \
+}
+
/* this function is for tracing only, it's not optimized for performance */
static int is_modperl_filter(ap_filter_t *f)
{
@@ -264,9 +277,7 @@
filter->mode = mode;
filter->f = f;
filter->pool = p;
-filter->wbucket.pool = p;
-filter->wbucket.filters = &f->next;
-filter->wbucket.outcnt = 0;
+filter->wbucket = NULL;
if (mode == MP_INPUT_FILTER_MODE) {
filter->bb_in = NULL;
@@ -739,7 +750,8 @@
filter->flush = 0;
}
-filter->rc = modperl_wbucket_flush(&filter->wbucket, add_flush_bucket);
+WBUCKET_INIT(filter->wbucket, filter->pool, filter->f->next);
+filter->rc = modperl_wbucket_flush(filter->wbucket, add_flush_bucket);
if (filter->rc != APR_SUCCESS) {
return filter->rc;
}
@@ -779,7 +791,8 @@
const char *buf,
apr_size_t *len)
{
-return modperl_wbucket_write(aTHX_ &filter->wbucket, buf, len);
+WBUCKET_INIT(filter->wbucket, filter->pool, filter->f->next);
+return modperl_wbucket_write(aTHX_ filter->wbucket, buf, len);
}
apr_status_t modperl_output_filter_handler(ap_filter_t *f,
Index: src/modules/perl/modperl_types.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_types.h,v
retrieving revision 1.69
diff -u -r1.69 modperl_types.h
--- src/modules/perl/modperl_types.h19 Aug 2003 05:01:22 - 1.69
+++ src/modules/perl/modperl_types.h11 Dec 2003 09:20:46 -
@@ -193,7 +193,7 @@
ap_filter_t *f;
char *leftover;
apr_ssize_t remaining;
-modperl_wbucket_t wbucket;
+modperl_wbucket_t *wbucket;
apr_bucket *bucket;
apr_bucket_brigade *bb_in;
apr_bucket_brigade *bb_out;
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 filters] allocating modperl_wbucket_t or not
Stas Bekman wrote: > Currently we allocate a wbucket of type modperl_wbucket_t for each > filter invocation. If it's not a streaming filter (i.e. manipulates > bucket brigades or doesn't use read/print) it's never going to need > wbucket. wbucket consumes 16404 bytes, the filter struct without > wbucket consumes 60 bytes. In order not to penalize non-streaming > filters, I suggest not to allocate wbucket if and not until it's first > used. you're still way ahead of the game here, so go with what you think is best (thanks for asking, though :) if you have the time and can explain what a wbucket is, that would be great, too :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>>> so maybe at startup it's not a bad idea after all :)
>>
>>
>>
>> So, does this mean that you don't have a specific objection against
>> deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
>> future in favor of ->add_config("User foo") ?
>
>
> The problem with add_config() is that it wants a string as if you've
> written it in httpd.conf language. Taking an access to
> %Apache::ReadConfig:: away takes away the ability to use perl structs to
> autovivify complex constructs. e.g. how do you build a complex vhost
> with nested containers using add_config?
well, it might be different than it was, but I guess it ends up being
similar to Apache->httpd_conf
Apache->server->add_config([ <
ServerName $name
ServerAlias $alias
END
in truth, now that I look at it, I'm not sure that's any more or less
difficult or flexible than
%directives = (
ServerName=> $name,
ServerAlias => $alias,
);
$VirtualHost{$vhost} = \%directives;
especially when you take in to account that extra steps are needed for when
ordering is important (like rewrite rules).
>
> may be we could have an alternative method, accepting an SV (e.g. a hash
> ref which represents a container) which perl will then convert to a
> string and feed to add_config?
I suppose that could work too.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 filters] allocating modperl_wbucket_t or not
Geoffrey Young wrote: Stas Bekman wrote: Currently we allocate a wbucket of type modperl_wbucket_t for each filter invocation. If it's not a streaming filter (i.e. manipulates bucket brigades or doesn't use read/print) it's never going to need wbucket. wbucket consumes 16404 bytes, the filter struct without wbucket consumes 60 bytes. In order not to penalize non-streaming filters, I suggest not to allocate wbucket if and not until it's first used. I'm getting too comphy with pools and this patch of course forgets to free memory, now that it has moved to malloc. you're still way ahead of the game here, so go with what you think is best (thanks for asking, though :) Are you talking about premature optimization, or are you just implying that you hadn't caught up with filters implementation yet? if you have the time and can explain what a wbucket is, that would be great, too :) modperl_wbucket_t is a struct that mod_perl uses to pass data to from response handler to the first filter, or from any mod_perl filter to the next filter. e.g. it's used every time ($r|$f)->(print()|flush()) and some other variants are called. It includes a buffer of fixed size and a few other records. It's very efficient in the response handlers, since it's allocated only once for each request. Only filters that use streaming API and call $f->print() need this buffer. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
Geoffrey Young wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
so maybe at startup it's not a bad idea after all :)
So, does this mean that you don't have a specific objection against
deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
future in favor of ->add_config("User foo") ?
The problem with add_config() is that it wants a string as if you've
written it in httpd.conf language. Taking an access to
%Apache::ReadConfig:: away takes away the ability to use perl structs to
autovivify complex constructs. e.g. how do you build a complex vhost
with nested containers using add_config?
well, it might be different than it was, but I guess it ends up being
similar to Apache->httpd_conf
Yup
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_httpd_conf_
(and I have a typo in it, will fix shortly)
Apache->server->add_config([ <
ServerName $name
ServerAlias $alias
END
in truth, now that I look at it, I'm not sure that's any more or less
difficult or flexible than
%directives = (
ServerName=> $name,
ServerAlias => $alias,
);
$VirtualHost{$vhost} = \%directives;
but that's a simple example. If you want to have more complex config and if
you have some engine that generates each component separately it's going to be
harder to put them together. It's just so intuitive to use perl structs for
that purpose.
especially when you take in to account that extra steps are needed for when
ordering is important (like rewrite rules).
True. One needs to use Tie::IxHash for this purpose.
may be we could have an alternative method, accepting an SV (e.g. a hash
ref which represents a container) which perl will then convert to a
string and feed to add_config?
I suppose that could work too.
Cool.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 filters] allocating modperl_wbucket_t or not
>> you're still way ahead of the game here, so go with what you think is >> best >> (thanks for asking, though :) > > > Are you talking about premature optimization, or are you just implying > that you hadn't caught up with filters implementation yet? definitely the latter - I'm still very far behind in my understanding of all the low-C-level filter stuff. that's what I meant :) > >> if you have the time and can explain what a wbucket is, that would be >> great, >> too :) > > > modperl_wbucket_t is a struct that mod_perl uses to pass data to from > response handler to the first filter, or from any mod_perl filter to the > next filter. e.g. it's used every time ($r|$f)->(print()|flush()) and > some other variants are called. > It includes a buffer of fixed size and a few other records. It's very > efficient in the response handlers, since it's allocated only once for > each request. > > Only filters that use streaming API and call $f->print() need this buffer. excellent, thanks! --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
what response code filters should return when they see c->aborted?
If the connection is aborted filters need to know how to deal with that situation and not waste resources processing data which is going to be dumped anyway. It's easy to do by checking c->aborted every so often. The question is, what's the proper response code should the filter return if it decides not to process data any longer since it saw c->aborted is true? AP_NOBODY_WROTE? AP_FILTER_ERROR? What's confusing is that it seems that most consumers (not filters) (e.g. in protocol.c) that call ap_pass_brigade are completely ignoring its response code. I suppose cleanly aborting the request is at least important for the logging purposes. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
>> especially when you take in to account that extra steps are needed for >> when >> ordering is important (like rewrite rules). > > > True. One needs to use Tie::IxHash for this purpose. or Tie::DxHash, depending on the complexity of what you need to accomplish. it's very messy. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what response code filters should return when they see c->aborted?
[sorry, it was meant to go to httpd-dev, now reposted ] Stas Bekman wrote: If the connection is aborted filters need to know how to deal with that situation and not waste resources processing data which is going to be dumped anyway. It's easy to do by checking c->aborted every so often. The question is, what's the proper response code should the filter return if it decides not to process data any longer since it saw c->aborted is true? AP_NOBODY_WROTE? AP_FILTER_ERROR? What's confusing is that it seems that most consumers (not filters) (e.g. in protocol.c) that call ap_pass_brigade are completely ignoring its response code. I suppose cleanly aborting the request is at least important for the logging purposes. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
On Thu, 2003-12-11 at 10:11, Stas Bekman wrote:
> Geoffrey Young wrote:
> >
> > Stas Bekman wrote:
> >
> >>Philippe M. Chiasson wrote:
> >>
> >>
> so maybe at startup it's not a bad idea after all :)
> >>>
> >>>
> >>>
> >>>So, does this mean that you don't have a specific objection against
> >>>deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
> >>>future in favor of ->add_config("User foo") ?
> >>
> >>
> >>The problem with add_config() is that it wants a string as if you've
> >>written it in httpd.conf language. Taking an access to
> >>%Apache::ReadConfig:: away takes away the ability to use perl structs to
> >>autovivify complex constructs. e.g. how do you build a complex vhost
> >>with nested containers using add_config?
> >
> >
> > well, it might be different than it was, but I guess it ends up being
> > similar to Apache->httpd_conf
>
> Yup
> http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_httpd_conf_
> (and I have a typo in it, will fix shortly)
>
> > Apache->server->add_config([ < >
> > ServerName $name
> > ServerAlias $alias
> >
> > END
> >
> > in truth, now that I look at it, I'm not sure that's any more or less
> > difficult or flexible than
> >
> > %directives = (
> >
> > ServerName=> $name,
> > ServerAlias => $alias,
> > );
> >
> > $VirtualHost{$vhost} = \%directives;
>
> but that's a simple example. If you want to have more complex config and if
> you have some engine that generates each component separately it's going to be
> harder to put them together. It's just so intuitive to use perl structs for
> that purpose.
Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
to handle either a namespace name, or a hash ref, as in:
package My::Config;
$Location{'/foo'} = { [...] };
@Alias = qw(/this /that);
and
Apache::PerlSection->add_namespace("My::Config");
or
my %My::Config = (
'Location' => { '/foo' => { [...]}},
'Alias' => qw(/this /that),
);
and
Apache::PerlSection->add_hash(\%My::Config);
So, in the end, we can have it all ;-) (method names subject to change
though)
> > especially when you take in to account that extra steps are needed for when
> > ordering is important (like rewrite rules).
>
> True. One needs to use Tie::IxHash for this purpose.
Yes, I am aware of this problem, and will be fixing it as well.
> >>may be we could have an alternative method, accepting an SV (e.g. a hash
> >>ref which represents a container) which perl will then convert to a
> >>string and feed to add_config?
> >
> >
> > I suppose that could work too.
See above examples.
> Cool.
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [Patch mp2] PerlSections namespace
Philippe M. Chiasson wrote:
[...]
Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
to handle either a namespace name, or a hash ref, as in:
package My::Config;
$Location{'/foo'} = { [...] };
@Alias = qw(/this /that);
and
Apache::PerlSection->add_namespace("My::Config");
or
my %My::Config = (
'Location' => { '/foo' => { [...]}},
'Alias' => qw(/this /that),
);
and
Apache::PerlSection->add_hash(\%My::Config);
So, in the end, we can have it all ;-) (method names subject to change
though)
yay, beautiful! gozer++
and then we will deprecate Apache::ReadConfig on its own.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
to handle either a namespace name, or a hash ref, as in:
package My::Config;
$Location{'/foo'} = { [...] };
@Alias = qw(/this /that);
and
Apache::PerlSection->add_namespace("My::Config");
or
my %My::Config = (
'Location' => { '/foo' => { [...]}},
'Alias' => qw(/this /that),
);
and
Apache::PerlSection->add_hash(\%My::Config);
ah, it can be an array or a scalar too, so a more generic name would be a
better choice, I believe. just call it add()? or add_var()?
Also if you prototype add() to accept an SV, you won't need to pass a
reference, which is confusing in the case of a scalar.
In which case we may want to provide an equivalent to add_config() as well.
Since they all add config. e.g. have:
Apache::PerlSection->add_namespace("My::Config");
Apache::PerlSection->add_string("User $foo");
my %hash = ...;
Apache::PerlSection->add(%hash);
notice that add_string is exactly the same as $s->add_config.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2 filters] allocating modperl_wbucket_t or not
Stas Bekman wrote:
Geoffrey Young wrote:
Stas Bekman wrote:
Currently we allocate a wbucket of type modperl_wbucket_t for each
filter invocation. If it's not a streaming filter (i.e. manipulates
bucket brigades or doesn't use read/print) it's never going to need
wbucket. wbucket consumes 16404 bytes, the filter struct without
wbucket consumes 60 bytes. In order not to penalize non-streaming
filters, I suggest not to allocate wbucket if and not until it's first
used.
I'm getting too comphy with pools and this patch of course forgets to
free memory, now that it has moved to malloc.
Here is a proper patch, which now frees the memory for wbucket as well.
Index: src/modules/perl/modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.77
diff -u -r1.77 modperl_filter.c
--- src/modules/perl/modperl_filter.c 11 Dec 2003 07:38:41 - 1.77
+++ src/modules/perl/modperl_filter.c 11 Dec 2003 19:26:57 -
@@ -20,6 +20,25 @@
#define MP_FILTER_POOL(f) f->r ? f->r->pool : f->c->pool
+/* allocate wbucket memory using malloc and not request pools, since
+ * we may need many of these if the filter is invoked multiple
+ * times */
+#define WBUCKET_INIT(wb, p, next_filter) \
+if (!wb) { \
+wb = (modperl_wbucket_t *)safemalloc(sizeof(*wb)); \
+wb->pool= p; \
+wb->filters = &next_filter;\
+wb->outcnt = 0; \
+wb->r = NULL;\
+wb->header_parse = 0; \
+}
+
+#define FILTER_FREE(filter)\
+if (filter->wbucket) { \
+safefree(filter->wbucket); \
+} \
+safefree(filter);
+
/* this function is for tracing only, it's not optimized for performance */
static int is_modperl_filter(ap_filter_t *f)
{
@@ -264,9 +283,7 @@
filter->mode = mode;
filter->f = f;
filter->pool = p;
-filter->wbucket.pool = p;
-filter->wbucket.filters = &f->next;
-filter->wbucket.outcnt = 0;
+filter->wbucket = NULL;
if (mode == MP_INPUT_FILTER_MODE) {
filter->bb_in = NULL;
@@ -393,7 +410,7 @@
status = modperl_errsv(aTHX_ status, r, s);
}
-safefree(filter);
+FILTER_FREE(filter);
SvREFCNT_dec((SV*)args);
MP_INTERP_PUTBACK(interp);
@@ -739,7 +756,8 @@
filter->flush = 0;
}
-filter->rc = modperl_wbucket_flush(&filter->wbucket, add_flush_bucket);
+WBUCKET_INIT(filter->wbucket, filter->pool, filter->f->next);
+filter->rc = modperl_wbucket_flush(filter->wbucket, add_flush_bucket);
if (filter->rc != APR_SUCCESS) {
return filter->rc;
}
@@ -779,7 +797,8 @@
const char *buf,
apr_size_t *len)
{
-return modperl_wbucket_write(aTHX_ &filter->wbucket, buf, len);
+WBUCKET_INIT(filter->wbucket, filter->pool, filter->f->next);
+return modperl_wbucket_write(aTHX_ filter->wbucket, buf, len);
}
apr_status_t modperl_output_filter_handler(ap_filter_t *f,
@@ -800,7 +819,7 @@
filter = modperl_filter_new(f, bb, MP_OUTPUT_FILTER_MODE,
0, 0, 0);
status = modperl_run_filter(filter);
-safefree(filter);
+FILTER_FREE(filter);
}
switch (status) {
@@ -834,7 +853,7 @@
filter = modperl_filter_new(f, bb, MP_INPUT_FILTER_MODE,
input_mode, block, readbytes);
status = modperl_run_filter(filter);
-safefree(filter);
+FILTER_FREE(filter);
}
switch (status) {
Index: src/modules/perl/modperl_types.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_types.h,v
retrieving revision 1.69
diff -u -r1.69 modperl_types.h
--- src/modules/perl/modperl_types.h19 Aug 2003 05:01:22 - 1.69
+++ src/modules/perl/modperl_types.h11 Dec 2003 19:26:57 -
@@ -193,7 +193,7 @@
ap_filter_t *f;
char *leftover;
apr_ssize_t remaining;
-modperl_wbucket_t wbucket;
+modperl_wbucket_t *wbucket;
apr_bucket *bucket;
apr_bucket_brigade *bb_in;
apr_bucket_brigade *bb_out;
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Re: [Patch mp2] PerlSections namespace
On Thu, 2003-12-11 at 11:01, Stas Bekman wrote:
> > Yes, and I am planning on writing 2 subclasses to Apache::PerlSections
> > to handle either a namespace name, or a hash ref, as in:
> >
> > package My::Config;
> > $Location{'/foo'} = { [...] };
> > @Alias = qw(/this /that);
> > and
> > Apache::PerlSection->add_namespace("My::Config");
> >
> > or
> >
> > my %My::Config = (
> > 'Location' => { '/foo' => { [...]}},
> > 'Alias' => qw(/this /that),
> > );
> > and
> > Apache::PerlSection->add_hash(\%My::Config);
>
> ah, it can be an array or a scalar too, so a more generic name would be a
> better choice, I believe. just call it add()? or add_var()?
>
> Also if you prototype add() to accept an SV, you won't need to pass a
> reference, which is confusing in the case of a scalar.
Yes, I do like the sound of Apache::perlSection->add_[type]()
> In which case we may want to provide an equivalent to add_config() as well.
> Since they all add config. e.g. have:
>
> Apache::PerlSection->add_namespace("My::Config");
> Apache::PerlSection->add_string("User $foo");
> my %hash = ...;
> Apache::PerlSection->add(%hash);
Might as well accept this as well:
Apache::PerlSection->add_glob(\*My::Config);
> notice that add_string is exactly the same as $s->add_config.
I'll put this thread in todo/ and push it on my stack ;-)
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
[Patch mp2] #2 PerlSections namespace
Following this discussion:
http://marc.theaimsgroup.com/?t=10710004043&r=1&w=2
I've made a few adjustements and cleanups.
The following patch adds ModPerl::Util::file2package() to build a safe
package from a pathname or filename.
This is in turn used by sections to put each block in it's own
namespace.
Configuration data placed in Apache::ReadConfig:: directly is processed
after the end of each blocks to preserve current behaviour.
Should be marked as deprecated as soon as users can feed their own
configuration to Apache::PerlSections (not possible quite yet)
How about this?
Index: src/modules/perl/modperl_cmd.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.51
diff -u -I$Id: -r1.51 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 17 Nov 2003 01:11:06 - 1.51
+++ src/modules/perl/modperl_cmd.c 11 Dec 2003 19:42:00 -
@@ -363,6 +363,7 @@
modperl_handler_t *handler = NULL;
const char *package_name = NULL;
const char *line_header = NULL;
+const char *namespace = NULL;
int status = OK;
AV *args = Nullav;
SV *dollar_zero = Nullsv;
@@ -399,8 +400,16 @@
if (!(package_name = apr_table_get(options, "package"))) {
package_name = apr_pstrdup(p, MP_DEFAULT_PERLSECTION_PACKAGE);
-apr_table_set(options, "package", package_name);
}
+
+namespace = modperl_file2package(p, parms->directive->filename);
+
+package_name = apr_psprintf(p, "%s::%s::line_%d",
+package_name,
+namespace,
+parms->directive->line_num);
+
+apr_table_set(options, "package", package_name);
line_header = apr_psprintf(p, "\n#line %d %s\n",
parms->directive->line_num,
Index: src/modules/perl/modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.58
diff -u -I$Id: -r1.58 modperl_util.c
--- src/modules/perl/modperl_util.c 25 Nov 2003 20:31:29 - 1.58
+++ src/modules/perl/modperl_util.c 11 Dec 2003 19:42:00 -
@@ -769,3 +769,53 @@
}
}
#endif
+
+#define MP_VALID_PKG_CHAR(c) (isalnum(c) ||(c) == '_')
+#define MP_VALID_PATH_DELIM(c) ((c) == '/' || (c) =='\\')
+char *modperl_file2package(apr_pool_t *p, const char *file)
+{
+char *package;
+char *c;
+const char *f;
+int len = strlen(file)+1;
+
+/* First, skip invalid prefix characters */
+while (!MP_VALID_PKG_CHAR(*file)) {
+file++;
+len--;
+}
+
+/* Then figure out how big the package name will be like */
+for(f = file; *f; f++) {
+if (MP_VALID_PATH_DELIM(*f)) {
+len++;
+}
+}
+
+package = apr_pcalloc(p, len);
+
+/* Then, replace bad characters with '_' */
+for (c = package; *file; c++, file++) {
+if (MP_VALID_PKG_CHAR(*file)) {
+*c = *file;
+}
+else if (MP_VALID_PATH_DELIM(*file)) {
+
+/* Eliminate subsequent duplicate path delim */
+while (*(file+1) && MP_VALID_PATH_DELIM(*(file+1))) {
+file++;
+}
+
+/* path delim not until end of line */
+if (*(file+1)) {
+*c = *(c+1) = ':';
+c++;
+}
+}
+else {
+*c = '_';
+}
+}
+
+return package;
+}
Index: src/modules/perl/modperl_util.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.h,v
retrieving revision 1.48
diff -u -I$Id: -r1.48 modperl_util.h
--- src/modules/perl/modperl_util.h 22 Sep 2003 23:46:19 - 1.48
+++ src/modules/perl/modperl_util.h 11 Dec 2003 19:42:00 -
@@ -159,4 +159,5 @@
void modperl_apr_table_dump(pTHX_ apr_table_t *table, char *name);
#endif
+char *modperl_file2package(apr_pool_t *p, const char *file);
#endif /* MODPERL_UTIL_H */
Index: lib/Apache/PerlSections.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/PerlSections.pm,v
retrieving revision 1.1
diff -u -I$Id: -r1.1 PerlSections.pm
--- lib/Apache/PerlSections.pm 20 Oct 2003 17:44:48 - 1.1
+++ lib/Apache/PerlSections.pm 11 Dec 2003 19:42:00 -
@@ -13,6 +13,7 @@
use Apache::Const -compile => qw(OK);
use constant SPECIAL_NAME => 'PerlConfig';
+use constant SPECIAL_PACKAGE => 'Apache::ReadConfig';
sub new {
my($package, @args) = @_;
@@ -54,24 +55,28 @@
sub symdump {
my($self) = @_;
-my $pack = $self->package;
-
unless ($self->{symbols}) {
-$self->{symbols} = [];
-
no strict;
-
-#XXX: Shamelessly borrowed from Devel::S
Re: [mp2 filters] allocating modperl_wbucket_t or not
On Thu, 2003-12-11 at 11:35, Stas Bekman wrote:
> Stas Bekman wrote:
> > Geoffrey Young wrote:
> >
> >>
> >> Stas Bekman wrote:
> >>
> >>> Currently we allocate a wbucket of type modperl_wbucket_t for each
> >>> filter invocation. If it's not a streaming filter (i.e. manipulates
> >>> bucket brigades or doesn't use read/print) it's never going to need
> >>> wbucket. wbucket consumes 16404 bytes, the filter struct without
> >>> wbucket consumes 60 bytes. In order not to penalize non-streaming
> >>> filters, I suggest not to allocate wbucket if and not until it's first
> >>> used.
> >
> >
> > I'm getting too comphy with pools and this patch of course forgets to
> > free memory, now that it has moved to malloc.
>
> Here is a proper patch, which now frees the memory for wbucket as well.
Looks like a safe and good idea to me : stas++
> Index: src/modules/perl/modperl_filter.c
> ===
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
> retrieving revision 1.77
> diff -u -r1.77 modperl_filter.c
> --- src/modules/perl/modperl_filter.c 11 Dec 2003 07:38:41 - 1.77
> +++ src/modules/perl/modperl_filter.c 11 Dec 2003 19:26:57 -
> @@ -20,6 +20,25 @@
>
> [...]
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [mp2] mod_perl test suite fails
Volker Kroll wrote:
On Tue, 2003-12-09 at 18:57, Stas Bekman wrote:
Which probably means that your perl POSIX implementation is broken.
Wed Dec 10 12:15:18 [EMAIL PROTECTED]:~> su -
Password:
[EMAIL PROTECTED] root]# perl -le 'require POSIX; POSIX::setgid(99) or die
"failed to run: $@";'
[EMAIL PROTECTED] root]# perl -le 'require POSIX; POSIX::setuid(65534) or
die "failed to setuid: $@"; print -r q{/root} && -w _ && -x _ ? q{OK} :
q{NOK}; '
OK
Your nobody and my nobody are not the same nobody ;)
grep ^nobody /etc/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin
Can you please try this one:
% perl -le ' \
my($uid, $gid) = (getpwnam("nobody"))[2..3]; \
$( = $) = $gid+0; \
die "failed to change gid to $gid (now: $(, $))" if $( != $gid; \
$< = $> = $uid+0; \
die "failed to change uid to $uid (now: $<, $>)" if $< != $uid; \
print -r q{/root} && -w _ && -x _ ? q{OK} : q{NOK};'
BTW, it should work correctly no matter if you have nologin in /etc/passwd or not.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
Philippe M. Chiasson wrote: [...] I'll put this thread in todo/ and push it on my stack ;-) I hope you won't call detach() on it ;) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] #2 PerlSections namespace
Philippe M. Chiasson wrote:
Following this discussion:
http://marc.theaimsgroup.com/?t=10710004043&r=1&w=2
I've made a few adjustements and cleanups.
The following patch adds ModPerl::Util::file2package() to build a safe
package from a pathname or filename.
Do you think we should really expose it in the public API? package2filename is
clear and generic, but file2package does a few assumptions that might not be
suitable to users. Do you think it'll really speed up registry? If not I'd
keep it as an internal util function.
This is in turn used by sections to put each block in it's own
namespace.
Configuration data placed in Apache::ReadConfig:: directly is processed
after the end of each blocks to preserve current behaviour.
Should be marked as deprecated as soon as users can feed their own
configuration to Apache::PerlSections (not possible quite yet)
I'd deprecate it for a few releases to let people time to make the transition
and then completely drop the support (at the latest by 2.0 release).
How about this?
haven't tested, but conceptually looks good.
Index: src/modules/perl/modperl_cmd.c
+namespace = modperl_file2package(p, parms->directive->filename);
+
+package_name = apr_psprintf(p, "%s::%s::line_%d",
+package_name,
^
+namespace,
+parms->directive->line_num);
can this be a different name? It doesn't feel very good when you use
'package_name' to create 'package_name', e.g. call the component as
package_base_name?
+#define MP_VALID_PATH_DELIM(c) ((c) == '/' || (c) =='\\')
is it always '\\'? couldn't it be ""?
+char *modperl_file2package(apr_pool_t *p, const char *file)
+{
+char *package;
+char *c;
+const char *f;
+int len = strlen(file)+1;
+
+/* First, skip invalid prefix characters */
+while (!MP_VALID_PKG_CHAR(*file)) {
+file++;
+len--;
+}
+
+/* Then figure out how big the package name will be like */
+for(f = file; *f; f++) {
+if (MP_VALID_PATH_DELIM(*f)) {
+len++;
+}
+}
+
+package = apr_pcalloc(p, len);
+
+/* Then, replace bad characters with '_' */
+for (c = package; *file; c++, file++) {
+if (MP_VALID_PKG_CHAR(*file)) {
+*c = *file;
+}
+else if (MP_VALID_PATH_DELIM(*file)) {
+
+/* Eliminate subsequent duplicate path delim */
+while (*(file+1) && MP_VALID_PATH_DELIM(*(file+1))) {
+file++;
+}
+
+/* path delim not until end of line */
+if (*(file+1)) {
+*c = *(c+1) = ':';
+c++;
+}
+}
+else {
+*c = '_';
+}
+}
ayi, why does it look so much simpler in perl:
# Escape everything into valid perl identifiers
$package =~ s/([^A-Za-z0-9_])/sprintf("_%2x", unpack("C", $1))/eg;
# make sure that the sub-package doesn't start with a digit
$package =~ s/^(\d)/_$1/;
can't we mirror this 1:1 with much simpler code?
[...]
kudos on docs and tests!
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] #2 PerlSections namespace
Stas Bekman wrote: > Philippe M. Chiasson wrote: > >> Following this discussion: >> http://marc.theaimsgroup.com/?t=10710004043&r=1&w=2 >> >> I've made a few adjustements and cleanups. >> >> The following patch adds ModPerl::Util::file2package() to build a safe >> package from a pathname or filename. > > > Do you think we should really expose it in the public API? > package2filename is clear and generic, but file2package does a few > assumptions that might not be suitable to users. Do you think it'll > really speed up registry? If not I'd keep it as an internal util function. I haven't looked inside the cooker recently, so I really don't remember how it all works... but if we use package2file and/or file2package in registry someplace, then there's the potential that users will want to subclass registry and will thus require either function to emulate core. as I said, I'm not sure how we use either at the moment - bringing it up just in case :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] #2 PerlSections namespace
Geoffrey Young wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Following this discussion:
http://marc.theaimsgroup.com/?t=10710004043&r=1&w=2
I've made a few adjustements and cleanups.
The following patch adds ModPerl::Util::file2package() to build a safe
package from a pathname or filename.
Do you think we should really expose it in the public API?
package2filename is clear and generic, but file2package does a few
assumptions that might not be suitable to users. Do you think it'll
really speed up registry? If not I'd keep it as an internal util function.
I haven't looked inside the cooker recently, so I really don't remember how
it all works...
but if we use package2file and/or file2package in registry someplace, then
there's the potential that users will want to subclass registry and will
thus require either function to emulate core.
as I said, I'm not sure how we use either at the moment - bringing it up
just in case :)
They have that function. As you can see it doesn't do the same as Phillipe's one.
#
# func: make_namespace
# dflt: make_namespace
# desc: prepares the namespace
# args: $self - registry blessed object
# rtrn: the namespace
# efct: initializes the field: PACKAGE
#
sub make_namespace {
my $self = shift;
my $package = $self->namespace_from;
# Escape everything into valid perl identifiers
$package =~ s/([^A-Za-z0-9_])/sprintf("_%2x", unpack("C", $1))/eg;
# make sure that the sub-package doesn't start with a digit
$package =~ s/^(\d)/_$1/;
# prepend root
$package = $self->namespace_root() . "::$package";
$self->{PACKAGE} = $package;
return $package;
}
Again I'm fine with exposing package2file since it's deterministic. But not
with file2package. In fact we shouldn't expose any of these, they have very
little to do with mod_perl. The problem with exposing any functions is that
you can't change them later. So if we don't have to expose them, let's not do it.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
rfc: ModPerl::ModuleSetup
So now I have several modules that leave in the same package, work with both
mod_perl generations, though they need to know which version to build for at
the 'perl Makefile.PL' time. I've mentioned this issue several times already
and I have some code, that it'd be nice to have in the core of mp2, that can
tremendously simplify Makefile.PL, remove a lot of duplicated code and effort
and unify the way all 3rd party modules select between mp1 and mp2.
This module will need to be installed to the normal @INC, just like Apache2.pm
and not into Apache2/ subdir.
Here is Makefile.PL from Apache-Peek, most of which should be moved to that
module. I'm talking about functions:
satisfy_mp_generation;
satisfy_perl_generation;
wanted_mp_generation;
they all are documented below. If we can stick to the same API it'll make
users lives much easier. Please excuse me for lack of the real spec, I'll do
that later, meanwhile just take a look at the code and see if it sounds good
and whether you have other demands (and code that could be moved to that module).
use strict;
use Cwd;
use File::Spec::Functions;
use File::Path ();
use Config;
use Symbol;
use constant DEVEL => getpwuid($>) eq 'stas';
my $VERSION = '1.01';
my @clean_files = ();
my $mp_gen = satisfy_mp_generation();
my $perl_gen = satisfy_perl_generation();
#warn "using mp gen: $mp_gen, perl gen: $perl_gen\n";
# currently we support only 5.8-perlio
if ($perl_gen eq '5.8') {
die "Perl must be built with PerlIO support in order to use this module"
unless $Config{useperlio};
}
build_prepare($mp_gen, $perl_gen);
warn "Goind to build against mod_perl/$mod_perl::VERSION Perl/$]\n";
test_configure($mp_gen);
my %prereq = (
'Apache::Test' => 1.01,
'Devel::Peek' => 0.96,
);
my %common_opts = (
NAME => "Apache::Peek",
VERSION_FROM => "Peek.pm",
XSPROTOARG => '-noprototypes',
DEFINE => '-DMOD_PERL',
clean=> { FILES => "@clean_files", },
PREREQ_PM=> \%prereq,
);
if ($mp_gen == 1) {
require Apache::src;
my $inc = Apache::src->new->inc;
die "Can't find mod_perl header files installed" unless $inc;
require ExtUtils::MakeMaker;
ExtUtils::MakeMaker::WriteMakefile(
INC => $inc,
LIBS => [''],
%common_opts,
);
}
else {
require ModPerl::MM;
ModPerl::MM::WriteMakefile(
%common_opts,
);
}
sub build_prepare {
my($mp_gen, $perl_gen) = @_;
my $xs = "Peek.xs";
my $pm = "Peek.pm";
push @clean_files, ($pm, $xs);
# now put together the build
my %files = map { $_ => join '.', $_, "mp$mp_gen", "perl$perl_gen" }
($pm, $xs);
unlink $xs if -e $xs;
if (DEVEL and eval { symlink("", ""); 1 }) {
# so that it's easier to modify/rebuild w/o re-running Makefile.PL
symlink $files{$xs}, $xs
or die "Couldn't symlink $files{$xs} => $xs: $!";
} else {
# copy the xs file as is
require File::Copy;
File::Copy::copy($files{$xs}, $xs);
}
# adjust the version and glue the doc (open() for 5.005_03 support)
my ($in, $out) = ($files{$pm}, $pm);
my ($ifh, $ofh) = (Symbol::gensym(), Symbol::gensym());
open $ifh, "<$in" or die "can't open $in: $!";
open $ofh, ">$out" or die "can't open $out: $!";
print $ofh "# WARNING: DO NOT EDIT THIS FILE, EDIT $in instead\n\n";
while (<$ifh>) {
s/(.*\$VERSION\s*=).*/$1 $VERSION;/;
print $ofh $_;
}
print $ofh ;
close $ifh;
close $ofh;
}
sub test_configure {
my $mp_gen = shift;
if (eval { require Apache::TestMM }) {
Apache::TestMM->import(qw(test clean));
my @scripts = qw(t/TEST);
# accept the configs from command line
Apache::TestMM::filter_args();
Apache::TestMM::generate_script($_) for @scripts;
push @clean_files, @scripts;
my $httpd;
# mp2 already knows its
if ($mp_gen == 1) {
#require Apache::test;
## can't really use get_test_params, since it may pick the wrong httpd
## must explicitly ask for the path to httpd
#my %params = Apache::test->get_test_params;
#$common_opts{macro}{APACHE} = $httpd;
}
} else {
warn "***: You should install Apache::Test to do real testing\n";
# META: soon on CPAN
*MY::test = sub {
return <<'EOF';
test : pure_all
@echo \*** This test suite requires Apache::Test available from the
@echo \*** mod_perl 2.0 sources or the httpd-test distribution.
EOF
}
}
}
sub satisfy_perl_generation {
eval { require 5.8.0 }? "5.8"
: eval { require 5.6.0 }? "5.6"
: eval { require 5.005_03 } ? "5.5"
: die "Perl version $] is unsupported";
}
# If a specific generation was passed as an argument,
# if satisfied
# return the same generation
# else
# die
# else @ARGV and %ENV will be checked for specific orders
Re: [mp2] raising the default startup timeout
Geoffrey Young wrote: Stas Bekman wrote: As our test suite grows it takes more and more time to start the server, the worker mpm almost always fail to start within 60 secs on my machine (which is pretty fast). And now we get reports from users who run prefork and it takes 68 secs to start. yikes. I got 49 seconds last night, so I guess it is pretty close So I'd suggest to make the default per server mpm and not one for all and go with 120 secs for prefork and 180 worker/winnt. If it sometimes takes more than 90 secs to start worker on my machine, I can see it hitting 3 minutes on a slower machine. I'm in favor so long as the change is mod_perl specific - no need to burden the entire apache community with perl's bloat :) now commmitted. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CPAN indexing on Apache-Test
This may be an unsolveable problem, but when using CPAN.pm to explore Apache-Test, some strange things arise: [EMAIL PROTECTED] randy]$ cpan cpan shell -- CPAN exploration and modules installation (v1.76) ReadLine support enabled cpan> m Apache::Test Module id = Apache::Test DESCRIPTION Framework for testing Apache modules CPAN_USERID STAS (Stas Bekman <[EMAIL PROTECTED]>) CPAN_VERSION 1.06 CPAN_FILEG/GE/GEOFF/Apache-Test-1.06.tar.gz DSLI_STATUS Smph (standard,mailing-list,perl,hybrid) MANPAGE Apache::Test - Test.pm wrapper with helpers for testing Apache INST_FILE/usr/local/lib/perl5/site_perl/5.8.1/Apache/Test.pm INST_VERSION 1.06 cpan> m Apache::TestRun Module id = Apache::TestRun CPAN_USERID STAS (Stas Bekman <[EMAIL PROTECTED]>) CPAN_VERSION undef CPAN_FILEG/GE/GEOFF/Apache-Test-1.06.tar.gz MANPAGE Apache::TestRun - Run the test suite INST_FILE/usr/local/lib/perl5/site_perl/5.8.1/Apache/TestRun.pm INST_VERSION undef cpan> m Apache::TestRunPerl Module id = Apache::TestRunPerl CPAN_USERID STAS (Stas Bekman <[EMAIL PROTECTED]>) CPAN_VERSION undef CPAN_FILEG/GE/GEOFF/Apache-Test-1.05.tar.gz MANPAGE INST_FILE/usr/local/lib/perl5/site_perl/5.8.1/Apache/TestRunPerl.pm INST_VERSION undef cpan> m Apache::TestSmoke Module id = Apache::TestSmoke CPAN_USERID STAS (Stas Bekman <[EMAIL PROTECTED]>) CPAN_VERSION undef CPAN_FILEG/GE/GEOFF/Apache-Test-1.05.tar.gz MANPAGE Apache::TestSmoke - Special Tests Sequence Failure Finder INST_FILE/usr/local/lib/perl5/site_perl/5.8.1/Apache/TestSmoke.pm INST_VERSION undef The difference between the CPAN_USERID and CPAN_FILE user is perhaps at best confusing, but what's also strange (and perhaps a problem for users) is that different CPAN_FILE versions are reported. So, if a user asks to install Apache::TestRunPerl, version 1.05 will be fetched, while asking for Apache::TestRun will fetch 1.06. Might this have to do with the versions of these modules being undefined? -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
