You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/01/15 01:41:55 UTC
[mp2] killing the ghost Apache:: usage?
Please take a look at this new manpage
http://perl.apache.org/docs/2.0/api/Apache.html
This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was OK to
have functions like Apache::current_callback() because almost everything was
preloaded. I don't think it's OK in mp2. It's absolutely not obvious which
module needs to be loaded to get this API, and most people will try to load
Apache, and it won't do the trick.
Why not replace:
use ModPerl::Util;
my $callback = Apache::current_callback();
with:
use ModPerl::Util;
my $callback = ModPerl::Util::current_callback();
then:
use Apache::ServerUtil;
my $server_root = Apache::server_root;
with:
use Apache::ServerUtil;
my $server_root = Apache::ServerUtil::server_root;
etc. (there are many modules which install things into the Apache::
namespace). i.e. try to use the same namespace as the module the function
lives in.
The only obvious need-to-keep is Apache->server, which can really be made a
constant too.
or do you think it's OK the way things are right now? The manpage suggests to
use http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html to figure
what needs to be loaded, but it's not so intuitive.
The only real problem with this change suggestion is backwards compatibility,
which is nice to keep small.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Sonntag, 18. Januar 2004 07:14 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >>>
> >>>and im sure my next project start with this lines too. If someone ask
> >>> why my answer is I do not know, but it does not work otherwise.
> >>
> >>And that's fine. Think of mp2 as a bunch of CPAN modules. You need to
> >> load them before you can use them.
> >
> > That is fine and reasonable to me. My point is that once I have an object
> > I want to be sure that I can use every method for this object. For
> > example this implies that whenever I have a RequestRec object that can
> > print, I must be sure that I can do so without loading Apache::RequestIO.
> >
> > It is ok to 'use APR::Date' if I like to use a function of it or operate
> > on a object that I can produce. But it is not ok in my opinion that my
> > Apache::RequestRec object gets magical date methods.
>
> But none of Apache::Request* classes is a subclass of each other. There is
> no inheritance tree. All they do is nicely spread the methods across
> several modules, giving you better fine tuning. So when you get $r in your
That is exactly my objection. It is like AUTOLOAD by hand.
> handler we have no idea what methods you are going to need, and which
> classes you need to load. It's quite possible that you never going to use
> Apache::RequestRec, so any guessing is wrong.
No guessing need at all. If I never need anything from $r I do not 'use
Apache::RequestRec'. What I expect is that whenever I have a object of type
X::Y, I can use every method of that object from the time on where I do a
'use X::Y;'. Even more I expect that no other modules change this behavior.
And how do you document this? Add a note in Apache::RequestRec for method x
that can only be used if you use the Apache::RequestFoo module? Also in the
docs for Apache::RequestFoo must be noted that there is no object of type
Apache::RequestFoo nor any function. And all methods from Apache::RequestFoo
infurence Apache::RequestRec. Another drawback is that I need a tool that
tell me which modues I need to use method xyz. This information must be
manualy transfered into my source.
This is a big help on migration but a beak for development.
>
> I think the best solution for your kind of pain is the one that Josh has
> proposed:
>
> use Apache::whatever qw(:request);
>
> and you get all Apache::Request* modules loaded and now you have all the
> mp2 methods that you can operate on $r.
This is nice, but only a workaround for the questionable practice. Im sure
nearly every module starts with this lines and then the reason for this
( IMHO save some bytes of nice sharable readonly data ) is completely
disabled. But it keeps all drawbacks.
If I try to profit, my only save bet is to read the ready source line by line,
writedown every mp2 method, run the list to mp2method_lookup and type that in
front of my handler. I do not think that anybody does so in practice.
>
> use Apache::whatever qw(:request :server);
>
> and you get Apache::Request* and Apache::Server* loaded. That is very
> similar to how CGI.pm imports its function interface symbols via tags,
> though here we deal with modules.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Sonntag, 18. Januar 2004 01:32 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>>
>>>Hi,
>>>
>>>Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman:
>>>
>>>>Please take a look at this new manpage
>>>>http://perl.apache.org/docs/2.0/api/Apache.html
>>>>
>>>>This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was
>>>>OK to have functions like Apache::current_callback() because almost
>>>>everything was preloaded. I don't think it's OK in mp2. It's absolutely
>>>>not obvious which module needs to be loaded to get this API, and most
>>>>people will try to load Apache, and it won't do the trick.
>>>
>>>This is very confusing and incomprehencible to me. My last mp2
>>>application starts with:
>>>
>>>use mod_perl 1.99;
>>>use Apache::RequestRec ();
>>>use Apache::RequestIO ();
>>>use Apache::ServerUtil ();
>>>use Apache::RequestUtil ();
>>>use Apache::Util ();
>>>use APR::Date ();
>>>use APR::Table();
>>>
>>>and im sure my next project start with this lines too. If someone ask why
>>>my answer is I do not know, but it does not work otherwise.
>>
>>And that's fine. Think of mp2 as a bunch of CPAN modules. You need to load
>>them before you can use them.
>
>
> That is fine and reasonable to me. My point is that once I have an object I
> want to be sure that I can use every method for this object. For example this
> implies that whenever I have a RequestRec object that can print, I must be
> sure that I can do so without loading Apache::RequestIO.
>
> It is ok to 'use APR::Date' if I like to use a function of it or operate on a
> object that I can produce. But it is not ok in my opinion that my
> Apache::RequestRec object gets magical date methods.
But none of Apache::Request* classes is a subclass of each other. There is no
inheritance tree. All they do is nicely spread the methods across several
modules, giving you better fine tuning. So when you get $r in your handler we
have no idea what methods you are going to need, and which classes you need to
load. It's quite possible that you never going to use Apache::RequestRec, so
any guessing is wrong.
I think the best solution for your kind of pain is the one that Josh has proposed:
use Apache::whatever qw(:request);
and you get all Apache::Request* modules loaded and now you have all the mp2
methods that you can operate on $r.
use Apache::whatever qw(:request :server);
and you get Apache::Request* and Apache::Server* loaded. That is very similar
to how CGI.pm imports its function interface symbols via tags, though here we
deal with modules.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Sonntag, 18. Januar 2004 01:32 schrieb Stas Bekman:
> Boris Zentner wrote:
> > Hi,
> >
> > Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman:
> >>Please take a look at this new manpage
> >>http://perl.apache.org/docs/2.0/api/Apache.html
> >>
> >>This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was
> >> OK to have functions like Apache::current_callback() because almost
> >> everything was preloaded. I don't think it's OK in mp2. It's absolutely
> >> not obvious which module needs to be loaded to get this API, and most
> >> people will try to load Apache, and it won't do the trick.
> >
> > This is very confusing and incomprehencible to me. My last mp2
> > application starts with:
> >
> > use mod_perl 1.99;
> > use Apache::RequestRec ();
> > use Apache::RequestIO ();
> > use Apache::ServerUtil ();
> > use Apache::RequestUtil ();
> > use Apache::Util ();
> > use APR::Date ();
> > use APR::Table();
> >
> > and im sure my next project start with this lines too. If someone ask why
> > my answer is I do not know, but it does not work otherwise.
>
> And that's fine. Think of mp2 as a bunch of CPAN modules. You need to load
> them before you can use them.
That is fine and reasonable to me. My point is that once I have an object I
want to be sure that I can use every method for this object. For example this
implies that whenever I have a RequestRec object that can print, I must be
sure that I can do so without loading Apache::RequestIO.
It is ok to 'use APR::Date' if I like to use a function of it or operate on a
object that I can produce. But it is not ok in my opinion that my
Apache::RequestRec object gets magical date methods.
>
> I guess people will appreaciate this separation once they will run mp2 in
> production. mp2 comes with more than 40 modules and more than 400 methods.
> Compared to 3 modules in mp1 (which you still had to load, remember!) and
> some 100 methods. If mp2 did what mp1 did you will get too much unnecessary
> bloat.
>
> > perldoc does not know anything of the above.
>
> because of the Apache2 issue. You need to use mp2doc (and it needs to be
> documented) or patch perldoc to load 'use Apache2'.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman:
>
>>Please take a look at this new manpage
>>http://perl.apache.org/docs/2.0/api/Apache.html
>>
>>This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was OK
>>to have functions like Apache::current_callback() because almost everything
>>was preloaded. I don't think it's OK in mp2. It's absolutely not obvious
>>which module needs to be loaded to get this API, and most people will try
>>to load Apache, and it won't do the trick.
>>
>
>
> This is very confusing and incomprehencible to me. My last mp2 application
> starts with:
>
> use mod_perl 1.99;
> use Apache::RequestRec ();
> use Apache::RequestIO ();
> use Apache::ServerUtil ();
> use Apache::RequestUtil ();
> use Apache::Util ();
> use APR::Date ();
> use APR::Table();
>
> and im sure my next project start with this lines too. If someone ask why my
> answer is I do not know, but it does not work otherwise.
And that's fine. Think of mp2 as a bunch of CPAN modules. You need to load
them before you can use them.
I guess people will appreaciate this separation once they will run mp2 in
production. mp2 comes with more than 40 modules and more than 400 methods.
Compared to 3 modules in mp1 (which you still had to load, remember!) and some
100 methods. If mp2 did what mp1 did you will get too much unnecessary bloat.
> perldoc does not know anything of the above.
because of the Apache2 issue. You need to use mp2doc (and it needs to be
documented) or patch perldoc to load 'use Apache2'.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Montag, 19. Januar 2004 15:03 schrieb Geoffrey Young:
> > If the example function is_initial_req() does not use a record of
> > request_rec and you think it makes no sense to define it in
> > Apache::RequestRec then my conclusion is it makes also no sense to do a
> > $r->is_initial_req() for the same reason and I'm happy to use
> > Apache::RequestUtil::is_initial_req($r);
>
> I don't understand this: is_initial_req() _does_ require a request_rec in
> C, thus is _does_require $r in Perl.
I know that. I dont mean a function or method without $r as parameter it is
where is_initial_req and friends are defined.
Geoffrey wrote:
> now, take a method like is_initial_req(), which represents access to
> ap_is_initial_req. the call only makes sense at request-time, and the
> Apache API requires a request_rec structure.
>but it doesn't make sense to
> define it in Apache::RequestRec, since it does not access a property of the
> request_rec structure.
In this context it makes sens or not? Quoting myself:
>> If the example function is_initial_req() does not use a record of
> > request_rec and you think it makes no sense to define it in
> > Apache::RequestRec then my conclusion is it makes also no sense to do a
> > $r->is_initial_req() for the same reason and I'm happy to use
> > Apache::RequestUtil::is_initial_req($r);
>
> > If it turns out that it is worth to have a $r->is_initial_req() it must
> > be defined in Apache::RequestRec. This way it is also possible to change
> > this method in subclasses of Apache::RequestRec.
>
> subclassing already works. that is, currently if you subclass
> Apache::RequestRec you can define your own is_initial_req(). you just need
> to subclass Apache::RequestRec in the way the docs describe (which is the
> same way as mp1).
>
Yes I know, but it works only if you export the method in another namespace my
main objection.
> in other words, everything is DWIM, save the need to load modules up front.
>
> > Maybe the Apache::RequestRec is the wrong name since a perl user dont
> > want a mirror of the C API or structs he want objects that do things easy
> > WITH whatever API.
>
> I strongly disagree with this. mod_perl is access to the Apache C API in
> Perl - the more they look the same (and the more people that understand
> this) the better.
Ahh this is the source of the difference, I suppose the goal of mp2 is to
build perlish interface to work with apache build around the C API. Your goal
seems to mirror the C API to perl as close as possible.
>
> --Geoff
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
> I don't think so. beneath it all each object method needs access to the c
>
>request_rec, and $r needs to keep its singleton nature. which doesn't mean
>you can't subclass it, you just need to use the bless { r => $r}, $class
>syntax. that's what I meant by "the same way you can normal Perl objects" -
>subclasses have a non-standard syntax.
>
>
>
I typically call the superclass constructor and then re-bless the
result, or else simply inherit the constructor completely. Those
approaches would still work, wouldn't they?
>>I always thought it was pointlessly dangerous to subclass $r in mp1, but
>>I know people did it with alarming frequency.
>>
>>
>
>I've never seen it be dangerous, though I suspect it could be abused. but
>it's also amazingly powerful
>
>
I just mean that people sometimes seem to subclass and create an "is a"
relationship when a simple "has a" relationship (a pointer from some
other object) would work just as well.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Stas Bekman wrote:
>
>> I don't have much to comment on these issues. I'm not going to repeat
>> again and again why the separation into multiple modules is important.
>
>
>
> I don't think anyone would have a problem with the multiple files, if we
> can just hide that unexpected complexity from end users.
+1
>> It may be unimportant to many users, but we aren't going to take it
>> away from those who need the ultimate performance.
>
>
>
> My suggestion about autoloading would not take away anyone's ability to
> preload things. It would help people who are not sure what they need
> yet though, and avoid worrying about what to preload until you are ready
> to do performance tuning.
please re-read my reply to this earlier suggestion of yours. In order to use
AUTOLOAD'ing you need to load that module that contains the wrappers first. It
[Apache::RequestRec] is not loaded by default and it won't be loaded by
default because it is not always needed. That means that the user still needs
to load something. And that's where my wrapper suggestion [Apache::whatever]
comes in.
>> Granted we want to make simple things easy and complicated possible.
>> And that's exactly why I've suggested to create another easy layer for
>> those users who don't care about saving a few msecs here and there and
>> don't care about a few hundreds extra k's of memory wasted. Why don't
>> you like that suggestion?
>
>
>
> Because it's not transparent. People still have to think about what
> they are going to load in a very early stage, and they still need to
> know which files (or import sets) the methods they call on $r are
> defined in. If they get it wrong, their program will die.
IF they call preload_all_modules() at the server startup, it'll just work.
> It also doesn't address the docs issue.
That's a good point. But this is an easy problem to solve. For example,
methods in other manpages can be cross referenced. e.g.:
Apache::RequestRec
TOC
Methods living in this package
...
Apache::RequestRec Methods living in other packages
...
...
I'm sure we can come up with some other good ideas.
OF course what you seem to be advocating is to throw all Apache::RequestRec
Methods in one package and therefore it solves the loading problem and the
documenation at once.
> With an autoload scheme, we can have a little app that tells you what to
> add to your startup.pl when tuning or we can have a flag that prints
> that info to the error log when it autoloads something. People can feel
> comfortable with the fact that their app will still work if they forget
> to preload something.
>
>> You want to preload all modules, go for it.
>
>
>
> I think that would be a better default than the current scenario, at
> least for $r (load everything by default, and have import options that
> load specific things instead), but autoload seems like a better
> compromise. And this doesn't address the docs issue either.
Where do you put the limit? You suggest to load all modules for $r, but many
modperl modules need many other modules, to work on $s, etc. You have one need
someone else will have another need for what needs to be loaded by default. I
see no better solution than loading everything by default and having a config
option which will prevent this from happening. So you will start with a
working mp2 no matter what, just like it was mostly for mp1 (minus several
modules that you *did* have to load before you could use them, like Apache::Log)
> Is there a technical reason why autoloading the $r methods wouldn't work?
IMHO, there is no need for it. You either want to fine tune and you load only
what you need. Or you don't care and you load them all. I fail to see why do
we need to complicate things any further.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> I don't have much to comment on these issues. I'm not going to repeat
> again and again why the separation into multiple modules is important.
I don't think anyone would have a problem with the multiple files, if we
can just hide that unexpected complexity from end users.
> It may be unimportant to many users, but we aren't going to take it
> away from those who need the ultimate performance.
My suggestion about autoloading would not take away anyone's ability to
preload things. It would help people who are not sure what they need
yet though, and avoid worrying about what to preload until you are ready
to do performance tuning.
> Granted we want to make simple things easy and complicated possible.
> And that's exactly why I've suggested to create another easy layer for
> those users who don't care about saving a few msecs here and there and
> don't care about a few hundreds extra k's of memory wasted. Why don't
> you like that suggestion?
Because it's not transparent. People still have to think about what
they are going to load in a very early stage, and they still need to
know which files (or import sets) the methods they call on $r are
defined in. If they get it wrong, their program will die. It also
doesn't address the docs issue.
With an autoload scheme, we can have a little app that tells you what to
add to your startup.pl when tuning or we can have a flag that prints
that info to the error log when it autoloads something. People can feel
comfortable with the fact that their app will still work if they forget
to preload something.
> You want to preload all modules, go for it.
I think that would be a better default than the current scenario, at
least for $r (load everything by default, and have import options that
load specific things instead), but autoload seems like a better
compromise. And this doesn't address the docs issue either.
Is there a technical reason why autoloading the $r methods wouldn't work?
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> as for your earlier suggestions, I was waiting for stas to comment on them.
I don't have much to comment on these issues. I'm not going to repeat again
and again why the separation into multiple modules is important. It may be
unimportant to many users, but we aren't going to take it away from those who
need the ultimate performance.
Granted we want to make simple things easy and complicated possible. And
that's exactly why I've suggested to create another easy layer for those users
who don't care about saving a few msecs here and there and don't care about a
few hundreds extra k's of memory wasted. Why don't you like that suggestion?
You want to preload all modules, go for it.
You want to preload all $r modules, go for it too. We can provide easy
wrappers that will do all that preloading for you. It's just a matter of
designing an intuitive API.
It doesn't have to be black or white.
This way everybody is happy and everyone can decide what's the best for them.
The only, but, is that we don't want these wrappers to be used in CPAN
modules. Exactly because we want to be able to control what's loaded and what not.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Neither is loading a bunch of modules that you don't actually access
> directly,
well...
> or using a program to look up where the docs for the method
> you're calling are. There are basic expectations that programmers have
> about when they need to load things and where they can find docs, and
> these are being foiled right now.
I agree totally with that. yet another thing that I thought sucked :)
> Incidentally, is there a decent tutorial for the apache 2 C API
> anywhere? The stuff I found on httpd.apache.org was pretty thin.
not that I know about. ryan bloom's book I think is the closest, but I've
not read it.
> I'm not complaining about $r, but rather about the inconsistency between
> calling the methods on Apache::RequestRec but loading them and reading
> their docs in other classes..
the docs are definitely an issue.
>
>> granted, $r is not a typical Perl object, but it can't be
>>
>
> I don't understand why.
well, for one it's singleton-esque, which makes it kinda unique.
>
>> and you can't subclass $r's underlying class the same
>> way you can normal Perl objects.
>>
>>
>
> Why not? Because of the stuff I'm complaining about?
I don't think so. beneath it all each object method needs access to the c
request_rec, and $r needs to keep its singleton nature. which doesn't mean
you can't subclass it, you just need to use the bless { r => $r}, $class
syntax. that's what I meant by "the same way you can normal Perl objects" -
subclasses have a non-standard syntax.
>
> I always thought it was pointlessly dangerous to subclass $r in mp1, but
> I know people did it with alarming frequency.
I've never seen it be dangerous, though I suspect it could be abused. but
it's also amazingly powerful
>
>> there isn't much
>> different here than there was in mp1 wrt classes that add methods to $r,
>> just a bit more of it.
>>
>>
>
> No, there's tons more of it, and unlike mp1 it is for methods that
> people actually will need to use. The stuff in mp1 was pretty obscure.
:)
as for your earlier suggestions, I was waiting for stas to comment on them.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
>>In most languages, defining class A methods in class B would not even be
>>allowed, and I kind of wish it wasn't allowed in Perl either so we
>>wouldn't have to have this discussion.
>>
>>
>
>good thing Perl isn't most languages ;)
>
>
>
There are some legitimate uses for this feature (autoloading, code
generation), but the key is to hide all this from users of the API.
>I'll grant you that there is a bit
>of an initial learning curve wrt the module loading that at first feels
>quite painful (remember my NYC talk started with how all this sucks :)
>
>
Right. I think it should not suck. :)
>really, the API is quite nice: all request-time functions are $r object
>methods. that's what makes the mod_perl wrapper for Apache as it exists now
>so great - it's Perlish.
>
That's fine with me. What I want is to put all the docs for those
methods in Apache::RequestRec's POD, and not require users to load any
other modules to get access to them. I think the approach I outlined in
the other thread would work for the latter. I don't enough about how
the doc generation works to know what's required for the POD.
> doing something like
>Apache::RequestUtil::is_initial_req($r) (or whatever variant) is not very
>Perlish.
>
>
>
Neither is loading a bunch of modules that you don't actually access
directly, or using a program to look up where the docs for the method
you're calling are. There are basic expectations that programmers have
about when they need to load things and where they can find docs, and
these are being foiled right now.
>>Remember, most people programming mod_perl applications have never even
>>looked at the C API, and I don't think there's anything wrong with
>>that.
>>
>>
>
>me neither. I do think they would understand it better if they looked at is
>as a wrapper, though, but that's neither here nor there.
>
>
Incidentally, is there a decent tutorial for the apache 2 C API
anywhere? The stuff I found on httpd.apache.org was pretty thin.
> I think that's what users have now with $r.
>
>
>
I'm not complaining about $r, but rather about the inconsistency between
calling the methods on Apache::RequestRec but loading them and reading
their docs in other classes..
>granted, $r is not a typical Perl object, but it can't be
>
I don't understand why.
>and you can't subclass $r's underlying class the same
>way you can normal Perl objects.
>
>
Why not? Because of the stuff I'm complaining about?
I always thought it was pointlessly dangerous to subclass $r in mp1, but
I know people did it with alarming frequency.
>there isn't much
>different here than there was in mp1 wrt classes that add methods to $r,
>just a bit more of it.
>
>
No, there's tons more of it, and unlike mp1 it is for methods that
people actually will need to use. The stuff in mp1 was pretty obscure.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
our beloved API...
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
moving to a new thread, since there are multiple issues in the other one...
> In most languages, defining class A methods in class B would not even be
> allowed, and I kind of wish it wasn't allowed in Perl either so we
> wouldn't have to have this discussion.
good thing Perl isn't most languages ;)
>> mod_perl is access to the Apache C API in
>> Perl - the more they look the same (and the more people that understand
>> this) the better.
>>
>>
>
> Obviously keeping these close is good for development of mod_perl, but
> no one is going to use mp2 if the API is confusing and difficult.
well, I don't think it's either, really. I'll grant you that there is a bit
of an initial learning curve wrt the module loading that at first feels
quite painful (remember my NYC talk started with how all this sucks :)
really, the API is quite nice: all request-time functions are $r object
methods. that's what makes the mod_perl wrapper for Apache as it exists now
so great - it's Perlish. doing something like
Apache::RequestUtil::is_initial_req($r) (or whatever variant) is not very
Perlish.
> Remember, most people programming mod_perl applications have never even
> looked at the C API, and I don't think there's anything wrong with
> that.
me neither. I do think they would understand it better if they looked at is
as a wrapper, though, but that's neither here nor there.
> Doug seemed to recognize that an easy Perl API is a necessity
> when he designed the simple filter stuff.
yes, and I think that's what users have now with $r.
granted, $r is not a typical Perl object, but it can't be - $r is the same
object throughout the entire request, which is odd in and of itself. it
also has no real constructor, especially in mp2 where Apache->request
doesn't always work. and you can't subclass $r's underlying class the same
way you can normal Perl objects.
but I think all of this is ok - persistent, complex environments like
mod_perl have their quirks. and, as I said before, there isn't much
different here than there was in mp1 wrt classes that add methods to $r,
just a bit more of it.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
>>If the example function is_initial_req() does not use a record of request_rec
>>and you think it makes no sense to define it in Apache::RequestRec then my
>>conclusion is it makes also no sense to do a $r->is_initial_req() for the
>>same reason and I'm happy to use Apache::RequestUtil::is_initial_req($r);
>>
>>
For what it's worth, Boris and I are saying exactly the same thing here:
it makes no sense to require people to load class A in order to call a
method on class B. What we have now is like a manual version of
AutoLoader, but even worse since you have to go run a program in order
to figure out which file you have to load.
In most languages, defining class A methods in class B would not even be
allowed, and I kind of wish it wasn't allowed in Perl either so we
wouldn't have to have this discussion.
>in other words, everything is DWIM, save the need to load modules up front.
>
>
... but that is a huge problem. It also breaks the docs. If I am
supposed to call is_initial_req() on $r, then the docs for that method
have to be in the Apache::RequestRec POD, since $r is a RequestRec object.
>mod_perl is access to the Apache C API in
>Perl - the more they look the same (and the more people that understand
>this) the better.
>
>
Obviously keeping these close is good for development of mod_perl, but
no one is going to use mp2 if the API is confusing and difficult.
Remember, most people programming mod_perl applications have never even
looked at the C API, and I don't think there's anything wrong with
that. Doug seemed to recognize that an easy Perl API is a necessity
when he designed the simple filter stuff.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> If the example function is_initial_req() does not use a record of request_rec
> and you think it makes no sense to define it in Apache::RequestRec then my
> conclusion is it makes also no sense to do a $r->is_initial_req() for the
> same reason and I'm happy to use Apache::RequestUtil::is_initial_req($r);
I don't understand this: is_initial_req() _does_ require a request_rec in C,
thus is _does_require $r in Perl.
>
> If it turns out that it is worth to have a $r->is_initial_req() it must be
> defined in Apache::RequestRec. This way it is also possible to change this
> method in subclasses of Apache::RequestRec.
subclassing already works. that is, currently if you subclass
Apache::RequestRec you can define your own is_initial_req(). you just need
to subclass Apache::RequestRec in the way the docs describe (which is the
same way as mp1).
in other words, everything is DWIM, save the need to load modules up front.
> Maybe the Apache::RequestRec is the wrong name since a perl user dont want a
> mirror of the C API or structs he want objects that do things easy WITH
> whatever API.
I strongly disagree with this. mod_perl is access to the Apache C API in
Perl - the more they look the same (and the more people that understand
this) the better.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Samstag, 17. Januar 2004 20:09 schrieb Geoffrey Young:
> > For the record, I agree with Boris on this. Users should never be
> > required to use methods defined in namespaces of modules that they did
> > not explicitly load, and modules should not define things in other
> > namespaces (like the Apache:: stuff that started this thread).
>
> well, there are a few reasons for all of this. granted, it doesn't really
> make sense before you, well, understand it, but I like it :) so, here's my
> view on the whole thing...
>
> take Apache::RequestRec. it implements methods that provde access to the
> apache request_rec structure. so, load it and you get access to things
> like $r->uri() and $r->notes(), which are stored as the uri and notes slots
> in the C request_rec.
>
> now, take a method like is_initial_req(), which represents access to
> ap_is_initial_req. the call only makes sense at request-time, and the
> Apache API requires a request_rec structure. but it doesn't make sense to
> define it in Apache::RequestRec, since it does not access a property of the
> request_rec structure. so, it's definition is elsewhere, in
> Apache::RequestUtil, but Apache::RequestUtil defines
> Apache::RequestRec::is_initial_req(). the end result is that you can have
> the Perlish $r->is_initial_req() instead of the bulky
If the example function is_initial_req() does not use a record of request_rec
and you think it makes no sense to define it in Apache::RequestRec then my
conclusion is it makes also no sense to do a $r->is_initial_req() for the
same reason and I'm happy to use Apache::RequestUtil::is_initial_req($r);
If it turns out that it is worth to have a $r->is_initial_req() it must be
defined in Apache::RequestRec. This way it is also possible to change this
method in subclasses of Apache::RequestRec.
> Apache::RequestUtil::is_initial_req($r). basically, in Perl we get an API
> that makes sense: operations that require a request_rec in C are called
> from $r in Perl.
>
>
> why not just define is_initial_req() in Apache::RequestRec? well, for one
> it makes for a cleaner design: each of request_rec, server_rec,
> connection_rec have their own classes that provide access only to the slots
> in their specific record. but another good thing is that if your
> application only needs access to notes() and other request_rec attributes,
> then your code profile isn't bloated with symbols for is_initial_req() and
> other non-request_rec methods.
This in not bloat it is part of my object! In my oppinion the function must
be part of both Apache::RequestRec and Apache::RequestUtil.
Maybe the Apache::RequestRec is the wrong name since a perl user dont want a
mirror of the C API or structs he want objects that do things easy WITH
whatever API.
>
> while this may feel new, it's actually not: in mp1 you couldn't call
> $r->log->info without first loading Apache::Log, nor could you call
> $r->meets_conditions without first loading Apache::File. I suspect (but
> don't know for certain) that this was an implementation style that popped
> up later in mp1's lifecycle, and that Doug decided it was the way mp2 ought
> to work.
>
> personally, I'm really in favor of the way things look now (save the things
> that started this thread). not only do they represent a cleaner Perl API
> layer (my favorite part) but they allow applications to keep unnecessary
> symbols out of their code. granted, it takes a while to get used to, but I
> like it and I hope it will grow on everyone as it has on me.
>
> --Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>For the record, I agree with Boris on this. Users should never be
>>required to use methods defined in namespaces of modules that they did
>>not explicitly load, and modules should not define things in other
>>namespaces (like the Apache:: stuff that started this thread).
>
>
> well, there are a few reasons for all of this. granted, it doesn't really
> make sense before you, well, understand it, but I like it :) so, here's my
> view on the whole thing...
[snipped the explanation of why being able to load each module separately is a
goodness ]
Josh Chamas has suggested some time ago to have a package which will preload
groups of modules. So if you don't care about fine tuned performance you could
say:
use Apache::whatever qw(:request :server);
and it'll load Apache::Request* and Apache::Server*. We can define more groups.
Still some of these methods return objects which require other packages to be
loaded. So dir_config requires APR::Table to be loaded, etc. So I'm not sure
how much win this is going to make.
And again, we won't want this Apache::whatever module to be used in CPAN
modules, and rather have the authors load explicitly only the modules that
really need to.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Dienstag, 20. Januar 2004 21:13 schrieb Stas Bekman:
> Boris Zentner wrote:
> > Hi,
[..]
> >>> Where do you install that
> >>>AUTOLOAD on functions or modules which aren't $r or $s operators?
> >>
> >>I don't want to AUTOLOAD anything that isn't called through one of
> >>those.
> >
> > This is exactly what I try to say for the last x mails. Whenever I act
> > with a object of type x, I do a 'use x;'. Here a example I can use print
> > without RequestIO but sure I must load APR::Table to use method set.
> >
> > use APR::Table;
> > use Apache::RequestRec;
> > sub handler : method {
> > my $r = shift;
> > $r->print('xx');
> > my $t = $r->notes;
> > $t->set('foo');
> > }
>
> That's not what Perrin is talking about I think. So you do suggest that a
> user need to load 'Apache::RequestRec' to get $r methods?
No and yes, I do it so because the name is now ApacheRec for your convinience.
I suggest a Apache::RequestHandle like Perrin that has all methods of
Apache::RequestRec, Apache::RequestIO and other Apache::Request*. If the
bloat seems to high to carry that all in one class, outsource with autoload
( or another aproach ) the key point is one package to load for all methods
of $x. I load Apache::RequestHandle whenever I do something with the object
that is more than store or pass through something else.
The advantage is that one can do perldoc Apache::RequestHandle or mp2doc
Apache::RequestHandle for the docs. And there is no need to remember that
method print is from Apache::RequestIO as it is now.
>
> Perrin suggests that you don't need to load anything from your code,
> because you already receive $r, so the methods should be there already.
> Compared to the situation where you create the object by yourself. So if I
> understand Perrin's vision, that code should work with:
>
> use APR::Table;
> sub handler : method {
> my $r = shift;
> $r->print('xx');
> my $t = $r->notes;
> $t->set('foo');
> }
>
> my problem is why $r is magical, but not $t. Why inconsistency? if you
> didn't create $t, you shouldn't need to load APR::Table, it should be there
> for you, just like with $r.
>
No we remove the magic namespace foo from Apache::Request* and
Apache::Server*.
> So as you can see your and Perrin's views aren't exactly the same. Please
> correct me if I'm wrong.
I think Perrin's view is exactly or very close to my view.
I'm courios about it. ;-)
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Dienstag, 20. Januar 2004 22:04 schrieb Perrin Harkins:
> On Tue, 2004-01-20 at 16:02, Boris Zentner wrote:
> > just to clarify it, I mean it like Perrin but not that stong, I have no
> > problem to load a package to use it. My problem is to load package bar to
> > fill methods for package foo.
>
> When someone passes your handler a live $r object, you shouldn't have to
> load that module to use it, since the code that is passing you $r must
> have already loaded the class in order to make a $r object. On the
> other hand, if you need to actually call a method like
> Apache::RequestRec->foo() then you should explicitly load that class.
My view is very close. Just one difference, I do not expect that the class is
already loaded. If I get a object of type $r I have to make sure that I load
the package of type ref $r myself.
I think of it like a object that is thawed and passed to me. Maybe from
another computer or out of a database. So I make the use statement. But my
View is included in Perrin's.
>
> - Perrin
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Mittwoch, 21. Januar 2004 05:41 schrieb Stas Bekman:
> but again, this is all sugar features and I won't worry about them now, as
> they can work no matter how the methods are spread across the manpages.
Right, I have a lot more ideas for the mp2doc/perldoc features. I deferred
them for now. What I like for now is even for
mp2doc -f Apache::RequestRec::read
the whole man page for Apache::RequestRec not only the part about the read
method. I have changed my mind about that a little since if I get a page like
Apache::RequestWhatever it is hard to scan for other
features/methods/examples for the package/class I'm using.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
> lets suppose that we use mp2doc to search. Or even better patch perldoc.
I doubt it's a good idea. Imagine every project trying to add their things and
flags into perldoc. You can be sure that perldoc maintainers will say 'no'.
Besides it won't help all those with the older perls.
[...]
> whenever I think of it, my conclusion is to use one big page for every
> package.
>
> mp2doc Apache::RequestRec read
>
> should load Apache::RequestRec.pod and jump to the read description of that
> method.
that's a sugar feature. I won't worry about it now.
>>it's possible that we will need to have different solutions for command
>>line and web utils, unless we throw all methods into one manpage.
>>
>>...just brainstorming aloud here, throw your ideas please ...
>
>
> choose the flags in a way that did not overlap with perldoc.
You can never know which flags will be used by perldoc in the future. Unless
you safely prefix them with something like -mp2 as you have mentioned ealier.
if mp2doc is used only for mp2 docs then the need for the special flag
disappears. And you can do:
mp2doc Apache::RequestRec
or
mp2doc -f read # ala perldoc -f
and it will either show you the page or ask you which one you want to see if
there are more than one. Of course:
mp2doc -f Apache::RequestRec::read
should show you the right page right away
but again, this is all sugar features and I won't worry about them now, as
they can work no matter how the methods are spread across the manpages.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Mittwoch, 21. Januar 2004 01:27 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >>
> >>but it doesn't quite follow your previous suggestion that you should be
> >>able to find *all* Apache::RequestRec object's methods in the
> >> manpage.
> >
> > I want this yes, I use perldoc X::Y and then / to search for my needs
> > that works fine also on very large pages. But if the file is to big for
> > that, I be content with a description like the above.
> >
> > Perhaps like this:
> > First a overview what the package is good for. Followed by the groups
> > where the detailed discription of each method is found. And a part where
> > *every* method is listed by name and one line discription and again where
> > it is documented. The key for me is that at least *all* methods for the
> > Apache::RequestRec are listed. At least with a pointer to the document.
>
> That's similar to what I suggested, but it's not very effective. If you go
> through the effort of doing all that, won't it be much faster to execute:
>
> lookup foo
maybe, but this suppose that I know foo. It is often the case that I know only
a packagename that have a method or function to help me. I like the weak
search from perldoc since often Im not sure which method to use and browse
up/down to read on the other methods or take a look on examples for this
method or another. The advantage of one big page.
>
> and it'll tell you which doc to look at? For the online docs we could just
> have one huge index of all methods with xrefs to the right manpages.
>
> In fact talking about command line utils, since we already have a utility
> mp2doc, which is needed to deal with Apache2/ subdirectory where the normal
lets suppose that we use mp2doc to search. Or even better patch perldoc.
> perldoc won't look for, I can't think why can't we plug the magical do-all
> lookup method which will find the right manpage for you:
>
> mp2doc -f content_type
>
> ala perldoc -f, though may be using a different flag, or no flag at all (it
> can magically figure out whether it's a method or a package name.
>
> though I'm not sure what to do with methods which have different
> implementation in different classes. e.g.:
>
> mp2doc -f read
perldoc -mp2 read
lists the three packages where a read method exists.
Apache::RequestRec
APR::Bucket
Apache::Filter
>
> read() has 3 different manpages, which one should we show? of course if you
> tell:
>
> mp2doc Apache::RequestRec read
>
> then it'll know that you are after Apache::RequestIO.
whenever I think of it, my conclusion is to use one big page for every
package.
mp2doc Apache::RequestRec read
should load Apache::RequestRec.pod and jump to the read description of that
method.
>
> it's possible that we will need to have different solutions for command
> line and web utils, unless we throw all methods into one manpage.
>
> ...just brainstorming aloud here, throw your ideas please ...
choose the flags in a way that did not overlap with perldoc.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Am Mittwoch, 21. Januar 2004 00:11 schrieb Stas Bekman:
>
>>>translated to mp2 this may look like
>>>
>>> Apache::Request(Rec|Handle) request record accessors
>>> Apache::RequestIO Discription of IO methods of
>>>Apache::RequestRec Apache::Request::* bla bla bla
>>>
>>>I hope the spaces are correct in your mailers. Just to be sure
>>>Apache::RequestIO and Apache::Request::* are indented.
>>
>>We have that already accomplished more or less. May be some more polishing
>>is needed.
>>
>>but it doesn't quite follow your previous suggestion that you should be
>>able to find *all* Apache::RequestRec object's methods in the
>> manpage.
>
>
> I want this yes, I use perldoc X::Y and then / to search for my needs that
> works fine also on very large pages. But if the file is to big for that, I be
> content with a description like the above.
>
> Perhaps like this:
> First a overview what the package is good for. Followed by the groups where
> the detailed discription of each method is found. And a part where *every*
> method is listed by name and one line discription and again where it is
> documented. The key for me is that at least *all* methods for the
> Apache::RequestRec are listed. At least with a pointer to the document.
That's similar to what I suggested, but it's not very effective. If you go
through the effort of doing all that, won't it be much faster to execute:
lookup foo
and it'll tell you which doc to look at? For the online docs we could just
have one huge index of all methods with xrefs to the right manpages.
In fact talking about command line utils, since we already have a utility
mp2doc, which is needed to deal with Apache2/ subdirectory where the normal
perldoc won't look for, I can't think why can't we plug the magical do-all
lookup method which will find the right manpage for you:
mp2doc -f content_type
ala perldoc -f, though may be using a different flag, or no flag at all (it
can magically figure out whether it's a method or a package name.
though I'm not sure what to do with methods which have different
implementation in different classes. e.g.:
mp2doc -f read
read() has 3 different manpages, which one should we show? of course if you tell:
mp2doc Apache::RequestRec read
then it'll know that you are after Apache::RequestIO.
it's possible that we will need to have different solutions for command line
and web utils, unless we throw all methods into one manpage.
...just brainstorming aloud here, throw your ideas please ...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Mittwoch, 21. Januar 2004 00:11 schrieb Stas Bekman:
> > translated to mp2 this may look like
> >
> > Apache::Request(Rec|Handle) request record accessors
> > Apache::RequestIO Discription of IO methods of
> > Apache::RequestRec Apache::Request::* bla bla bla
> >
> > I hope the spaces are correct in your mailers. Just to be sure
> > Apache::RequestIO and Apache::Request::* are indented.
>
> We have that already accomplished more or less. May be some more polishing
> is needed.
>
> but it doesn't quite follow your previous suggestion that you should be
> able to find *all* Apache::RequestRec object's methods in the
> manpage.
I want this yes, I use perldoc X::Y and then / to search for my needs that
works fine also on very large pages. But if the file is to big for that, I be
content with a description like the above.
Perhaps like this:
First a overview what the package is good for. Followed by the groups where
the detailed discription of each method is found. And a part where *every*
method is listed by name and one line discription and again where it is
documented. The key for me is that at least *all* methods for the
Apache::RequestRec are listed. At least with a pointer to the document.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Dienstag, 20. Januar 2004 22:31 schrieb Boris Zentner:
> Apache::Request::* bla bla bla
>
> I hope the spaces are correct in your mailers. Just to be sure
> Apache::RequestIO and Apache::Request::* are indented.
sorry I mean Apache::Request* _not_ Apache::Request::*
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Am Dienstag, 20. Januar 2004 22:17 schrieb Stas Bekman:
>
>>So my idea was to list all Apache::RequestRec methods in the
>>Apache::RequestRec manpage, but have the bodies of most of them spread
>>across Apache::RequestIO, etc, just like it is now. That's if you use the
>>web interface. It won't quite work for 'perldoc'.
>>
>>So now that you know what the problem is, please tell us your ideas on how
>>to approach that.
>
>
> Like perl does it already. for example:
>
> perldoc perl gives this list:
> ....
> perltrap Perl traps for the unwary
> perldebtut Perl debugging tutorial
>
> perlfaq Perl frequently asked questions
> perlfaq1 General Questions About Perl
> perlfaq2 Obtaining and Learning about Perl
> perlfaq3 Programming Tools
> perlfaq4 Data Manipulation
> perlfaq5 Files and Formats
> perlfaq6 Regexes
> perlfaq7 Perl Language Issues
> perlfaq8 System Interaction
> perlfaq9 Networking
>
> translated to mp2 this may look like
>
> Apache::Request(Rec|Handle) request record accessors
> Apache::RequestIO Discription of IO methods of Apache::RequestRec
> Apache::Request::* bla bla bla
>
> I hope the spaces are correct in your mailers. Just to be sure
> Apache::RequestIO and Apache::Request::* are indented.
We have that already accomplished more or less. May be some more polishing is
needed.
but it doesn't quite follow your previous suggestion that you should be able
to find *all* Apache::RequestRec object's methods in the Apache::RequestRec
manpage.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Dienstag, 20. Januar 2004 22:17 schrieb Stas Bekman:
> So my idea was to list all Apache::RequestRec methods in the
> Apache::RequestRec manpage, but have the bodies of most of them spread
> across Apache::RequestIO, etc, just like it is now. That's if you use the
> web interface. It won't quite work for 'perldoc'.
>
> So now that you know what the problem is, please tell us your ideas on how
> to approach that.
Like perl does it already. for example:
perldoc perl gives this list:
....
perltrap Perl traps for the unwary
perldebtut Perl debugging tutorial
perlfaq Perl frequently asked questions
perlfaq1 General Questions About Perl
perlfaq2 Obtaining and Learning about Perl
perlfaq3 Programming Tools
perlfaq4 Data Manipulation
perlfaq5 Files and Formats
perlfaq6 Regexes
perlfaq7 Perl Language Issues
perlfaq8 System Interaction
perlfaq9 Networking
translated to mp2 this may look like
Apache::Request(Rec|Handle) request record accessors
Apache::RequestIO Discription of IO methods of Apache::RequestRec
Apache::Request::* bla bla bla
I hope the spaces are correct in your mailers. Just to be sure
Apache::RequestIO and Apache::Request::* are indented.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Mittwoch, 11. Februar 2004 02:16 schrieb Stas Bekman:
> > Now my error message is
> >
> > Can't locate auto/Apache/Request/PageKit/headers_in.al
> >
> > So I think Apache::Request use a kind of ->can to check for a method
> > before it forwards it. This makes the EazyLife option useless for me. (
> > Or I have to support a kind of autoloader or preloader for my class, but
> > that make it useless too. )
>
> I think not. headers_in called on $r should have AUTOLOADED
> Apache::RequestRec. Now since you call it on Apache::Request::PageKit for
> some reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably
> a problem in either Apache::Request::PageKit or Apache::Request, with
> inheritance gone wrong.
>
Apache::Request::PageKit is my testclass for the port to MP2. It replaces the
old Apache::Request and is @ISA=qw/Apache::Request/;
A:R is unable to use real inherance and forward unknown methods to the
A:R->env object ( that is in my case Apache::RequestRec ). I think it tests
the availability of the method before it calls the method with ->can. And for
that reason it did not find the headers_in method. Since it is not loaded.
But that is untested so far.
> Does it work for you if you use a pure modperl handler/registry script?
More tomorrow; its to late already ( 3:01:33 )
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
>>>what if my class is
>>>
>>>package q;
>>>@ISA=('Apache::Filter', 'Apache::RequestIO');
>>>
>>>or look at DESTROY do we choice the right DESTROY?
>
>
> some what related:
> perl -MModPerl::MethodLookup -le ' \
> package Apache::RequestRec; sub new { bless {}, shift }; 1; \
> package My::Request; @ISA = qw(Apache::RequestRec); 1; \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY", $obj); \
> print $hint'
>
> To use method 'DESTROY' add:
> use APR::Pool ();
>
> but
>
> perl -MModPerl::MethodLookup -le ' \
> package Apache::RequestRec; sub new { bless {}, shift }; 1; \
> package My::Request; @ISA = qw(Apache::RequestRec); 1; \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY",
> "Apache::RequestRec"); \ print $hint'
>
> gives nothing.
I think it handles it correctly now. In prints now:
Several modules (APR::ThreadMutex, Apache::SubRequest, APR::Pool) contain
method 'DESTROY' but none of them matches class 'My::Request';
Several modules (APR::ThreadMutex, Apache::SubRequest, APR::Pool) contain
method 'DESTROY' but none of them matches class 'Apache::RequestRec';
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Mittwoch, 18. Februar 2004 00:37 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>
> [...]
>
>>>>>my $c = shift;
>>>>>$AUTOLOAD =~ /(\w+)$/;
>>>>>$c->$1(@_);
>>>>>
>>>>>looks funny, but the we need to handle the return part too. That might
>>>>>be not so nice for any case.
>>>>
>>>>Yes, that's not good. How about:
>>>>
>>>> if (@modules) {
>>>> eval "require $_" for @modules;
>>>> if (@modules == 1) {
>>>> my $module = shift @modules;
>>>> $AUTOLOAD =~ s/.*::/$module::/;
>>>> }
>>>> goto &$AUTOLOAD;
>>>> }
>>>>
>>>>really, I think it should always be only one matching module, since we
>>>>have no internal sub-classing at the moment.
>>>
>>>I can not belive, that this work.
>>
>>You mean it *does* work for you.
>
>
> No, it does not work.
Let me know if does work now, and if not what does not. Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Mittwoch, 18. Februar 2004 00:37 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >>>my $c = shift;
> >>>$AUTOLOAD =~ /(\w+)$/;
> >>>$c->$1(@_);
> >>>
> >>>looks funny, but the we need to handle the return part too. That might
> >>> be not so nice for any case.
> >>
> >>Yes, that's not good. How about:
> >>
> >> if (@modules) {
> >> eval "require $_" for @modules;
> >> if (@modules == 1) {
> >> my $module = shift @modules;
> >> $AUTOLOAD =~ s/.*::/$module::/;
> >> }
> >> goto &$AUTOLOAD;
> >> }
> >>
> >>really, I think it should always be only one matching module, since we
> >> have no internal sub-classing at the moment.
> >
> > I can not belive, that this work.
>
> You mean it *does* work for you.
No, it does not work.
>
> > what if my class is
> >
> > package q;
> > @ISA=('Apache::Filter', 'Apache::RequestIO');
> >
> > or look at DESTROY do we choice the right DESTROY?
some what related:
perl -MModPerl::MethodLookup -le ' \
package Apache::RequestRec; sub new { bless {}, shift }; 1; \
package My::Request; @ISA = qw(Apache::RequestRec); 1; \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY", $obj); \
print $hint'
To use method 'DESTROY' add:
use APR::Pool ();
but
perl -MModPerl::MethodLookup -le ' \
package Apache::RequestRec; sub new { bless {}, shift }; 1; \
package My::Request; @ISA = qw(Apache::RequestRec); 1; \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("DESTROY",
"Apache::RequestRec"); \ print $hint'
gives nothing.
>
> that is easily solvable by passing the class name the AUTOLOAD is called
> for instead of the real object.
>
> So if you call:
>
> package q;
> @ISA=('Apache::Filter', 'Apache::RequestIO');
> q->new->print();
>
> we do:
>
> for my $module (@avail_modules) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, $module);
>
> which translates into:
>
> lookup_method('q::print', 'Apache::Filter');
>
> since inheritance tree traversal goes left to right. Meaning that it'll
> find that Apache::Filter need to be loaded and then call:
>
> goto &Apache::Filter::print;
>
> The problem with that change is when a method which is not found in the
> first ISA class is not found. Actually the way lookup_method is implemented
> at the moment, it'll check the second argument only if it has more than 1
> hit. So if you call:
>
> q->new->sendfile();
>
> it'll still do the right thing. Apache::Filter::AUTOLOAD will load
> Apache::RequestIO and call:
>
> goto &Apache::RequestIO::sendfile;
>
> Regarding DESTROY, I think we are covered too. The only difference from the
> above explanation is that we don't croak if DESTROY is not found. Or do you
> see a hole in my logic?
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Dienstag, 17. Februar 2004 03:06 schrieb Stas Bekman:
>
>>>something like
>>>
>>>my $c = shift;
>>>$AUTOLOAD =~ /(\w+)$/;
>>>$c->$1(@_);
>>>
>>>looks funny, but the we need to handle the return part too. That might be
>>>not so nice for any case.
>>
>>Yes, that's not good. How about:
>>
>> if (@modules) {
>> eval "require $_" for @modules;
>> if (@modules == 1) {
>> my $module = shift @modules;
>> $AUTOLOAD =~ s/.*::/$module::/;
>> }
>> goto &$AUTOLOAD;
>> }
>>
>>really, I think it should always be only one matching module, since we have
>>no internal sub-classing at the moment.
>
>
> I can not belive, that this work.
You mean it *does* work for you.
> what if my class is
>
> package q;
> @ISA=('Apache::Filter', 'Apache::RequestIO');
>
> or look at DESTROY do we choice the right DESTROY?
that is easily solvable by passing the class name the AUTOLOAD is called for
instead of the real object.
So if you call:
package q;
@ISA=('Apache::Filter', 'Apache::RequestIO');
q->new->print();
we do:
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, $module);
which translates into:
lookup_method('q::print', 'Apache::Filter');
since inheritance tree traversal goes left to right. Meaning that it'll find
that Apache::Filter need to be loaded and then call:
goto &Apache::Filter::print;
The problem with that change is when a method which is not found in the first
ISA class is not found. Actually the way lookup_method is implemented at the
moment, it'll check the second argument only if it has more than 1 hit. So if
you call:
q->new->sendfile();
it'll still do the right thing. Apache::Filter::AUTOLOAD will load
Apache::RequestIO and call:
goto &Apache::RequestIO::sendfile;
Regarding DESTROY, I think we are covered too. The only difference from the
above explanation is that we don't croak if DESTROY is not found. Or do you
see a hole in my logic?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Dienstag, 17. Februar 2004 03:06 schrieb Stas Bekman:
> > something like
> >
> > my $c = shift;
> > $AUTOLOAD =~ /(\w+)$/;
> > $c->$1(@_);
> >
> > looks funny, but the we need to handle the return part too. That might be
> > not so nice for any case.
>
> Yes, that's not good. How about:
>
> if (@modules) {
> eval "require $_" for @modules;
> if (@modules == 1) {
> my $module = shift @modules;
> $AUTOLOAD =~ s/.*::/$module::/;
> }
> goto &$AUTOLOAD;
> }
>
> really, I think it should always be only one matching module, since we have
> no internal sub-classing at the moment.
I can not belive, that this work. what if my class is
package q;
@ISA=('Apache::Filter', 'Apache::RequestIO');
or look at DESTROY do we choice the right DESTROY?
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Donnerstag, 19. Februar 2004 11:03 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>>[...]
>>
>>
>>>>i.e. I can't reproduce your problem. Are you sure you are using the
>>>>latest cvs, did you run 'make install'?. There were quite a few changes
>>>>in the APR::Pool code over the last month.
>>>
>>>Yes, Im sure. But for some reason It did not crash for me too. I
>>>investigate.
>>
>>that's a good news (for me, hopefully no guessing will be needed). Now you
>>need to figure out how to make it crash, and hopefully it'll crash for me
>>too ;)
>
>
> It was easy, install this EazyLife too.
Ouch, of course ;)
The problem was due to a silly bug I've introduced in the lookup_method
function, matching the object to itself ;) Now should be fixed.
I was getting a segfault in the ModPerl-Registry's make test, but in
APR::ThreadMutex::DESTROY as I suppose my perl put that package before
APR::Pool ;)
'DESTROY' => [
[
'APR::ThreadMutex',
'APR::ThreadMutex'
],
[
'Apache::SubRequest',
'Apache::SubRequest'
],
[
'APR::Pool',
'APR::Pool'
]
],
So for me it was resolving Apache::Server::DESTROY as
APR::ThreadMutex::DESTROY and boom...
It should be fine in the cvs right now, I think.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Donnerstag, 19. Februar 2004 11:03 schrieb Stas Bekman:
> Boris Zentner wrote:
> [...]
>
> >>i.e. I can't reproduce your problem. Are you sure you are using the
> >> latest cvs, did you run 'make install'?. There were quite a few changes
> >> in the APR::Pool code over the last month.
> >
> > Yes, Im sure. But for some reason It did not crash for me too. I
> > investigate.
>
> that's a good news (for me, hopefully no guessing will be needed). Now you
> need to figure out how to make it crash, and hopefully it'll crash for me
> too ;)
It was easy, install this EazyLife too.
package ModPerl::EazyLife;
use ModPerl::MethodLookup ();
use Carp;
my @avail_modules = ModPerl::MethodLookup::avail_modules();
push @avail_modules, 'Apache'; # XXX: may go away
my $skip = qr|(::)?DESTROY$|;
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
# there should be only one match
if (my ($module) = @modules) {
eval "require $module";
# use the function from the module that we have just loaded
$AUTOLOAD =~ s/^.*::/${module}::/;
goto &$AUTOLOAD;
}
else {
return if $AUTOLOAD =~ /$skip/;
croak $hint || "Can't find $AUTOLOAD";
}
};
}
1;
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
>>i.e. I can't reproduce your problem. Are you sure you are using the latest
>>cvs, did you run 'make install'?. There were quite a few changes in the
>>APR::Pool code over the last month.
>>
>
>
> Yes, Im sure. But for some reason It did not crash for me too. I investigate.
that's a good news (for me, hopefully no guessing will be needed). Now you
need to figure out how to make it crash, and hopefully it'll crash for me too ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Am Donnerstag, 19. Februar 2004 09:51 schrieb Stas Bekman:
> Boris Zentner wrote:
> > Hi Stas,
> >
> > Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
> >>>(gdb) bt
> >>>#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
> >>>val=0x0) at apr_hash.c:278
> >>>#1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
> >>> at apr_hash.c:340
> >>>#2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
> >>> key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
> >>
> >>the pool object is bogus.
> >>
> >>>#3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
> >>> from
> >>>/home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/
> >>>P ool/Pool.so #4 0x4042c3b9 in Perl_pp_goto ()
> >>> from
> >>>/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so #5
> >>> 0x403f803e in Perl_runops_standard ()
> >>
> >>I've seen that one before. Can you show me a short code that I can
> >>reproduce this with?
> >
> > Ok, here it is ( minimal and useless ):
> >
> > I use './t/TEST --start-httpd' the server.
> >
> > My ./t/conf/extra.last.conf.in:
> > ######### START ##########
> > <Perl >
> >
> > </Perl>
> >
> > <Location />
> > SetHandler perl-script
> > PerlHandler +Foo
> > </Location>
> > ######### END ############
> > without the ### lines of course. Please note that the whitespace chars
> > are important. If you write
> >
> > <Perl >
> > </Perl>
> >
> > it works! ( Just a newline removed )
> >
> > and Foo.pm
> > ######### START ##########
> > package Foo;
> > use mod_perl 1.99;
> > sub handler : method {
> > my ( $class, $r ) = @_ ;
> > return 200;
> > }
> > ######### END ############
>
> OK, I've packaged your test case for you in self-contained test suite
> (attached as it's a tiny file).
>
thanks
> % tar xvzf apr-destroy.tgs
> % cd apr-destroy
> % perl Makefile.PL -httpd ~/httpd/prefork/bin/httpd && t/TEST -start
> Writing Makefile for bug-reporting-skeleton
> setting ulimit to allow core files
> ulimit -c unlimited; t/TEST -start
> server localhost.localdomain:8529 shutdown
> /home/stas/httpd/prefork/bin/httpd -d /tmp/apr-destroy/t -f
> /tmp/apr-destroy/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
> using Apache/2.0.49-dev (prefork MPM)
> waiting 60 seconds for server to start: ok (waited 6 secs)
> server localhost.localdomain:8529 started
>
> i.e. I can't reproduce your problem. Are you sure you are using the latest
> cvs, did you run 'make install'?. There were quite a few changes in the
> APR::Pool code over the last month.
>
Yes, Im sure. But for some reason It did not crash for me too. I investigate.
> Try to run this test suite and see what you get. Here is what I used for
> this test:
>
> % mp2bug
here is my output from mp2bug.
-------------8<---------- Start Bug Report ------------8<----------
1. Problem Description:
[DESCRIBE THE PROBLEM HERE]
2. Used Components and their Configuration:
*** mod_perl version 1.9913
***
using /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX => /home/ptest2/httpd2
MP_COMPAT_1X => 1
MP_GENERATE_XS => 1
MP_LIBNAME => mod_perl
MP_USE_DSO => 1
MP_USE_STATIC => 1
*** /home/ptest2/httpd2/bin/httpd -V
Server version: Apache/2.0.47
Server built: Oct 13 2003 17:19:44
Server's Module Magic Number: 20020903:4
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/home/ptest2/httpd2"
-D SUEXEC_BIN="/home/ptest2/httpd2/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /home/ptest2/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.21-99-default, archname=i686-linux-thread-multi
uname='linux foo 2.4.21-99-default #1 wed sep 24 13:30:51 utc 2003 i686
i686 i386 gnulinux '
config_args='-Dprefix=/home/ptest2 -Uversiononly -Dusethreads
-Duseshrplib=true -Dusedevel'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.1 (SuSE Linux)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Oct 13 2003 16:28:01
%ENV:
PERL_LWP_USE_HTTP_10="1"
@INC:
/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi
/home/ptest2/lib/perl5/5.8.1
/home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi
/home/ptest2/lib/perl5/site_perl/5.8.1
/home/ptest2/lib/perl5/site_perl
.
*** Packages of interest status:
Apache::Request: 2.02-dev
CGI : 3.00
LWP : 5.69
mod_perl : 1.9913
3. This is the core dump trace: (if you get a core dump):
[CORE TRACE COMES HERE]
This report was generated by /home/ptest2/bin/mp2bug on Thu Feb 19 09:54:52
2004 GMT.
[ your example removed ]
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
>
>>>(gdb) bt
>>>#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
>>>val=0x0) at apr_hash.c:278
>>>#1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
>>> at apr_hash.c:340
>>>#2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
>>> key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
>>
>>the pool object is bogus.
>>
>>
>>>#3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
>>> from
>>>/home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/P
>>>ool/Pool.so #4 0x4042c3b9 in Perl_pp_goto ()
>>> from
>>>/home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so #5
>>> 0x403f803e in Perl_runops_standard ()
>>
>>I've seen that one before. Can you show me a short code that I can
>>reproduce this with?
>
>
> Ok, here it is ( minimal and useless ):
>
> I use './t/TEST --start-httpd' the server.
>
> My ./t/conf/extra.last.conf.in:
> ######### START ##########
> <Perl >
>
> </Perl>
>
> <Location />
> SetHandler perl-script
> PerlHandler +Foo
> </Location>
> ######### END ############
> without the ### lines of course. Please note that the whitespace chars are
> important. If you write
>
> <Perl >
> </Perl>
>
> it works! ( Just a newline removed )
>
> and Foo.pm
> ######### START ##########
> package Foo;
> use mod_perl 1.99;
> sub handler : method {
> my ( $class, $r ) = @_ ;
> return 200;
> }
> ######### END ############
>
OK, I've packaged your test case for you in self-contained test suite
(attached as it's a tiny file).
% tar xvzf apr-destroy.tgs
% cd apr-destroy
% perl Makefile.PL -httpd ~/httpd/prefork/bin/httpd && t/TEST -start
Writing Makefile for bug-reporting-skeleton
setting ulimit to allow core files
ulimit -c unlimited; t/TEST -start
server localhost.localdomain:8529 shutdown
/home/stas/httpd/prefork/bin/httpd -d /tmp/apr-destroy/t -f
/tmp/apr-destroy/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.49-dev (prefork MPM)
waiting 60 seconds for server to start: ok (waited 6 secs)
server localhost.localdomain:8529 started
i.e. I can't reproduce your problem. Are you sure you are using the latest
cvs, did you run 'make install'?. There were quite a few changes in the
APR::Pool code over the last month.
Try to run this test suite and see what you get. Here is what I used for this
test:
% mp2bug
*** mod_perl version 1.9913
*** using
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/Apache2/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_APXS => /home/stas/httpd/prefork/bin/apxs
MP_CCOPTS => -Wall -Werror
MP_COMPAT_1X => 1
MP_DEBUG => 1
MP_GENERATE_XS => 1
MP_INST_APACHE2 => 1
MP_LIBNAME => mod_perl
MP_MAINTAINER => 1
MP_TRACE => 1
MP_USE_DSO => 1
MP_USE_GTOP => 1
*** /home/stas/httpd/prefork/bin/httpd -V
Server version: Apache/2.0.49-dev
Server built: Feb 18 2004 15:04:02
Server's Module Magic Number: 20020903:7
Architecture: 32-bit
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/home/stas/httpd/prefork"
-D SUEXEC_BIN="/home/stas/httpd/prefork/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration:
Platform:
osname=linux, osvers=2.6.0-1mdkenterprise, archname=i386-linux-thread-multi
uname='linux no.mandrakesoft.com 2.6.0-1mdkenterprise #1 smp thu dec 18
16:11:28 est 2003 i686 unknown unknown gnulinux '
config_args='-des -Dinc_version_list=5.8.2/i386-linux-thread-multi 5.8.2
5.8.1/i386-linux-thread-multi 5.8.1 5.8.0/i386-linux-thread-multi 5.8.0 5.6.1
5.6.0 -Darchname=i386-linux -Dcc=gcc -Doptimize=-O2 -fomit-frame-pointer -pipe
-march=i586 -mcpu=pentiumpro -Dprefix=/usr -Dvendorprefix=/usr
-Dsiteprefix=/usr -Dman3ext=3pm -Dcf_by=MandrakeSoft -Dmyhostname=localhost
-Dperladmin=root@localhost -Dd_dosuid -Ud_csh -Duseshrplib -Dusethreads'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro ',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.3.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Feb 3 2004 13:50:20
%ENV:
PERLDOC_PAGER="less -R"
PERL_LWP_USE_HTTP_10="1"
@INC:
/usr/lib/perl5/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/5.8.3
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.1
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
.
*** Packages of interest status:
Apache::Request: -
CGI : 3.00
LWP : 5.69
mod_perl : 1.2801, 1.9913
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Dienstag, 17. Februar 2004 19:51 schrieb Stas Bekman:
> > (gdb) bt
> > #0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14,
> > val=0x0) at apr_hash.c:278
> > #1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
> > at apr_hash.c:340
> > #2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
> > key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
>
> the pool object is bogus.
>
> > #3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
> > from
> > /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/P
> >ool/Pool.so #4 0x4042c3b9 in Perl_pp_goto ()
> > from
> > /home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so #5
> > 0x403f803e in Perl_runops_standard ()
>
> I've seen that one before. Can you show me a short code that I can
> reproduce this with?
Ok, here it is ( minimal and useless ):
I use './t/TEST --start-httpd' the server.
My ./t/conf/extra.last.conf.in:
######### START ##########
<Perl >
</Perl>
<Location />
SetHandler perl-script
PerlHandler +Foo
</Location>
######### END ############
without the ### lines of course. Please note that the whitespace chars are
important. If you write
<Perl >
</Perl>
it works! ( Just a newline removed )
and Foo.pm
######### START ##########
package Foo;
use mod_perl 1.99;
sub handler : method {
my ( $class, $r ) = @_ ;
return 200;
}
######### END ############
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> HI Stas,
>
> this has its problems too. It dumps core. After starting a server I see:
>
> Apache::Server::DESTROY
>
> lookup_method finds APR::Pool. And so we call
>
> APR::Pool::DESTROY
>
> this does not look wrong to me, if APR::Pool has a DESTROY function and
> Apache::Server isa APR::Pool.
>
> here a small part from my coredump.
>
> (gdb) bt
> #0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14, val=0x0)
> at apr_hash.c:278
> #1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
> at apr_hash.c:340
> #2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
> key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
the pool object is bogus.
> #3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
> from /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/Pool/Pool.so
> #4 0x4042c3b9 in Perl_pp_goto ()
> from /home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so
> #5 0x403f803e in Perl_runops_standard ()
I've seen that one before. Can you show me a short code that I can reproduce
this with?
> and some typos fixed in the test ModPerl::EazyLife.
thanks ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
HI Stas,
this has its problems too. It dumps core. After starting a server I see:
Apache::Server::DESTROY
lookup_method finds APR::Pool. And so we call
APR::Pool::DESTROY
this does not look wrong to me, if APR::Pool has a DESTROY function and
Apache::Server isa APR::Pool.
here a small part from my coredump.
(gdb) bt
#0 0x40135abe in find_entry (ht=0x80baeb0, key=0x406cf229, klen=14, val=0x0)
at apr_hash.c:278
#1 0x40135c58 in apr_hash_get (ht=0x80baeb0, key=0x406cf229, klen=-1)
at apr_hash.c:340
#2 0x40143d4d in apr_pool_userdata_get (data=0xbfffe858,
key=0x406cf229 "APR::Pool::new", pool=0x2) at apr_pools.c:1879
#3 0x406ce7a8 in XS_APR__Pool_DESTROY ()
from /home/ptest2/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi/auto/APR/Pool/Pool.so
#4 0x4042c3b9 in Perl_pp_goto ()
from /home/ptest2/lib/perl5/5.8.1/i686-linux-thread-multi/CORE/libperl.so
#5 0x403f803e in Perl_runops_standard ()
and some typos fixed in the test ModPerl::EazyLife.
Am Dienstag, 17. Februar 2004 03:12 schrieb Stas Bekman:
> Stas Bekman wrote:
> [...]
>
> > really, I think it should always be only one matching module, since we
> > have no internal sub-classing at the moment.
>
> Something like so:
>
> package ModPerl::EazyLife;
>
> use ModPerl::MethodLookup ();
> use Carp;
>
> my @avail_modules = ModPerl::MethodLookup::avail_modules();
> push @avail_modules, 'Apache'; # XXX: may go away
> my $skip = qr|(::)?DESTROY$|;
> for my $module (@avail_modules) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> # there should be only one match
> if (my $module = @modules) {
- if (my $module = @modules) {
+ if (my ($module) = @modules) {
> eval "require $module";
> # use the function from the module that we have just loaded
> $AUTOLOAD =~ s/.*::/$module::/;
- $AUTOLOAD =~ s/.*::/$module::/;
+ $AUTOLOAD =~ s/.*::/${module}::/;
> goto &$AUTOLOAD;
> }
> else {
> return if $AUTOLOAD =~ /$skip/;
> croak $hint || "Can't find $AUTOLOAD";
> }
> };
> }
>
> 1;
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
> really, I think it should always be only one matching module, since we
> have no internal sub-classing at the moment.
Something like so:
package ModPerl::EazyLife;
use ModPerl::MethodLookup ();
use Carp;
my @avail_modules = ModPerl::MethodLookup::avail_modules();
push @avail_modules, 'Apache'; # XXX: may go away
my $skip = qr|(::)?DESTROY$|;
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
# there should be only one match
if (my $module = @modules) {
eval "require $module";
# use the function from the module that we have just loaded
$AUTOLOAD =~ s/.*::/$module::/;
goto &$AUTOLOAD;
}
else {
return if $AUTOLOAD =~ /$skip/;
croak $hint || "Can't find $AUTOLOAD";
}
};
}
1;
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
Earlier you've raised an important point: AUTOLOADs slow things down with
DESTROY and evals, penalizing users who don't rely on this module.
In order not to penalize those who preload, I think that we need to somehow
undef AUTOLOADs as soon as the module is loaded. Though this is tricky with
cases like Apache::RequestRec, since Apache::RequestRec::AUTOLOAD handles
several other classes.
Ideas?
>>>>so lookup_method internally finds two entries. none of them matches
>>>>My::RequestRec. So it checks isa() and finds that the first entry
>>>>matches. It should now return 'Apache::RequestIO', which AUTOLOAD loads
>>>>and now when it calls goto, it calls that method.
>>>
>>>Yes, that is exactly what happened here. But it is wrong.
>>>from your example:
>>> Apache::RequestIO is returned. now
>>> eval { require 'Apache::RequestIO' } loads the class/package.
>>>
>>>but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and
>>>produce the endless loop. Since we need to call Apache::RequestRec::print
>>>_not_ My::RequestRec::print.
>>
>>I see. So we probably need to call:
>>
>>shift->$AUTOLOAD
>>
>
>
> something like
>
> my $c = shift;
> $AUTOLOAD =~ /(\w+)$/;
> $c->$1(@_);
>
> looks funny, but the we need to handle the return part too. That might be not
> so nice for any case.
Yes, that's not good. How about:
if (@modules) {
eval "require $_" for @modules;
if (@modules == 1) {
my $module = shift @modules;
$AUTOLOAD =~ s/.*::/$module::/;
}
goto &$AUTOLOAD;
}
really, I think it should always be only one matching module, since we have no
internal sub-classing at the moment.
>>then? which this time will find print() on its own, since Apache::RequestIO
>>is now loaded.
>>
>>Not sure about the AUTOLOAD goto magick though. Ideas?
>>
>>May be having method_lookup return the package name will allow us to call:
>>
>> Apache::RequestRec::print(@_);
>>
>>But if there is a way to call the object method via goto, that would be the
>>simplest way.
>>
>
>
> Without too much thinking I prefere if method_lookup would return the full
> qualified method name ( Apache::RequestRec::print ).
>
> Then we can call goto &$method.
That will probably require writing a new function, as this extra return
argument doesn't fit into the existing API. I think a simple s/// above should
do the trick.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Montag, 16. Februar 2004 12:39 schrieb Stas Bekman:
> Boris Zentner wrote:
> [...]
>
> >>so lookup_method internally finds two entries. none of them matches
> >>My::RequestRec. So it checks isa() and finds that the first entry
> >> matches. It should now return 'Apache::RequestIO', which AUTOLOAD loads
> >> and now when it calls goto, it calls that method.
> >
> > Yes, that is exactly what happened here. But it is wrong.
> > from your example:
> > Apache::RequestIO is returned. now
> > eval { require 'Apache::RequestIO' } loads the class/package.
> >
> > but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and
> > produce the endless loop. Since we need to call Apache::RequestRec::print
> > _not_ My::RequestRec::print.
>
> I see. So we probably need to call:
>
> shift->$AUTOLOAD
>
something like
my $c = shift;
$AUTOLOAD =~ /(\w+)$/;
$c->$1(@_);
looks funny, but the we need to handle the return part too. That might be not
so nice for any case.
> then? which this time will find print() on its own, since Apache::RequestIO
> is now loaded.
>
> Not sure about the AUTOLOAD goto magick though. Ideas?
>
> May be having method_lookup return the package name will allow us to call:
>
> Apache::RequestRec::print(@_);
>
> But if there is a way to call the object method via goto, that would be the
> simplest way.
>
Without too much thinking I prefere if method_lookup would return the full
qualified method name ( Apache::RequestRec::print ).
Then we can call goto &$method.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
>>Users who are after performance must not be penalized with this module
>>being preloaded. So it should be configurable, with default to be On.
>>
>>We probabably can instrument EazyLife to dump a list of modules, that it
>>has loaded during the scripts execution, on the server shutdown, to make it
>>easier for the users to know which modules to preload and eventually get
>>rid of EazyLife.
>>
>>PerlEazyLife <Off|On|OnInfo>
>
> That is a really usefull extension.
What is? The dump of the loaded modules or the configure option, or both?
> I thought of it, but I do not dare to ask
> for it.
What you do you mean, you don't dare to ask for it. You can even code it ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Mittwoch, 18. Februar 2004 00:47 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> Users who are after performance must not be penalized with this module
> being preloaded. So it should be configurable, with default to be On.
>
> We probabably can instrument EazyLife to dump a list of modules, that it
> has loaded during the scripts execution, on the server shutdown, to make it
> easier for the users to know which modules to preload and eventually get
> rid of EazyLife.
>
> PerlEazyLife <Off|On|OnInfo>
>
That is a really usefull extension. I thought of it, but I do not dare to ask
for it.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Montag, 16. Februar 2004 11:58 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>>[...]
>>
>>
>>>It works better, but not right. It has the same problems as the last one,
>>>but the other way around ;-)
>>>
>>>On my first test I found out that it is incredible slow. So iI move the
>>>
>>> return if $AUTOLOAD =~ /$skip/;
>>>
>>>line before the lookup_method. That is not right ever, your way looks
>>>much better, but it was so slow. Perhaps other ideas are around.
>>
>>What's slow? Are there too many calls to DESTROY? Can you add tracing to
>>figure out the reason?
>
>
> It was so slow that I thought it is not working at all. Yes it was eval and
> destroy. But I take a closer look later.
Users who are after performance must not be penalized with this module being
preloaded. So it should be configurable, with default to be On.
We probabably can instrument EazyLife to dump a list of modules, that it has
loaded during the scripts execution, on the server shutdown, to make it easier
for the users to know which modules to preload and eventually get rid of EazyLife.
PerlEazyLife <Off|On|OnInfo>
Also another way to deal with DESTROY calls is to autovivify them as noops.
my $noop = sub () {};
...
goto &$noop if /DESTROY$/;
or even:
use constant NOOP => '';
...
goto &NOOP if /DESTROY$/;
does this speed things up?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
>>so lookup_method internally finds two entries. none of them matches
>>My::RequestRec. So it checks isa() and finds that the first entry matches.
>>It should now return 'Apache::RequestIO', which AUTOLOAD loads and now when
>>it calls goto, it calls that method.
>
>
> Yes, that is exactly what happened here. But it is wrong.
> from your example:
> Apache::RequestIO is returned. now
> eval { require 'Apache::RequestIO' } loads the class/package.
>
> but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and produce
> the endless loop. Since we need to call Apache::RequestRec::print _not_
> My::RequestRec::print.
I see. So we probably need to call:
shift->$AUTOLOAD
then? which this time will find print() on its own, since Apache::RequestIO is
now loaded.
Not sure about the AUTOLOAD goto magick though. Ideas?
May be having method_lookup return the package name will allow us to call:
Apache::RequestRec::print(@_);
But if there is a way to call the object method via goto, that would be the
simplest way.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Montag, 16. Februar 2004 11:58 schrieb Stas Bekman:
> Boris Zentner wrote:
> [...]
>
> > It works better, but not right. It has the same problems as the last one,
> > but the other way around ;-)
> >
> > On my first test I found out that it is incredible slow. So iI move the
> >
> > return if $AUTOLOAD =~ /$skip/;
> >
> > line before the lookup_method. That is not right ever, your way looks
> > much better, but it was so slow. Perhaps other ideas are around.
>
> What's slow? Are there too many calls to DESTROY? Can you add tracing to
> figure out the reason?
It was so slow that I thought it is not working at all. Yes it was eval and
destroy. But I take a closer look later.
>
> I thought to do so originally (move it up), but there are DESTROY methods
> in some of the classes, so I don't think this is right (unless we manually
> look them up and cache and then skip lookup if it's not in the cache.
>
> > The second problem is if I have a class that inherits from another class
> > with splitted functions like Apache::RequestRec.
> >
> > package xxx;
> > @ISA='Apache::RequestRec';
> > sub new { bless $_[1], $_[0] }
> >
> > sub handler : method {
> > my ( $class, $rec ) = @_;
> > xxx->new( $rec )->print('hello world');
> > }
> >
> > then AUTOLOAD is called and found out, that Apache::RequestRec is the
> > superclass of xxx and that Apache::RequestIO must be loaded. We require
> > Apache::RequestRec and then goto subroutine xxx::print. That is an
> > endless loop, since it calls AUTOLOAD to find out about xxx::print. In
> > this case we must call Apache::RequestRec::print, but we do not know
> > about it we only know Apache::RequestIO.
>
> So there must be a bug in the code. That shouldn't be the case. Let's take
> the $obj->print() call for example. where $obj is a sub-class of
> Apache::RequestRec and let's say it's called My::RequestRec. The data we
> have is:
>
> 'print' => [
> [
> 'Apache::RequestIO',
> 'Apache::RequestRec'
> ],
> [
> 'Apache::Filter',
> 'Apache::Filter'
> ]
> ],
>
> so lookup_method internally finds two entries. none of them matches
> My::RequestRec. So it checks isa() and finds that the first entry matches.
> It should now return 'Apache::RequestIO', which AUTOLOAD loads and now when
> it calls goto, it calls that method.
Yes, that is exactly what happened here. But it is wrong.
from your example:
Apache::RequestIO is returned. now
eval { require 'Apache::RequestIO' } loads the class/package.
but the next line 'goto &$AUTOLOAD' calls My::RequestRec::print and produce
the endless loop. Since we need to call Apache::RequestRec::print _not_
My::RequestRec::print.
>
> This snippet I've quoted earlier shows that method_lookup returns
> 'Apache::RequestIO'
>
> perl -MModPerl::MethodLookup -le '\
> package Apache::RequestRec; sub new { bless {}, shift }; \
> package My::Request; @ISA = qw(Apache::RequestRec); \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj);
> \ print $hint'
> To use method 'print' add:
> use Apache::RequestIO ();
>
> What do you see different?
I see exactly what you see.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
> It works better, but not right. It has the same problems as the last one, but
> the other way around ;-)
>
> On my first test I found out that it is incredible slow. So iI move the
>
> return if $AUTOLOAD =~ /$skip/;
>
> line before the lookup_method. That is not right ever, your way looks much
> better, but it was so slow. Perhaps other ideas are around.
What's slow? Are there too many calls to DESTROY? Can you add tracing to
figure out the reason?
I thought to do so originally (move it up), but there are DESTROY methods in
some of the classes, so I don't think this is right (unless we manually look
them up and cache and then skip lookup if it's not in the cache.
> The second problem is if I have a class that inherits from another class with
> splitted functions like Apache::RequestRec.
>
> package xxx;
> @ISA='Apache::RequestRec';
> sub new { bless $_[1], $_[0] }
>
> sub handler : method {
> my ( $class, $rec ) = @_;
> xxx->new( $rec )->print('hello world');
> }
>
> then AUTOLOAD is called and found out, that Apache::RequestRec is the
> superclass of xxx and that Apache::RequestIO must be loaded. We require
> Apache::RequestRec and then goto subroutine xxx::print. That is an endless
> loop, since it calls AUTOLOAD to find out about xxx::print. In this case we
> must call Apache::RequestRec::print, but we do not know about it we only know
> Apache::RequestIO.
So there must be a bug in the code. That shouldn't be the case. Let's take the
$obj->print() call for example. where $obj is a sub-class of
Apache::RequestRec and let's say it's called My::RequestRec. The data we have is:
'print' => [
[
'Apache::RequestIO',
'Apache::RequestRec'
],
[
'Apache::Filter',
'Apache::Filter'
]
],
so lookup_method internally finds two entries. none of them matches
My::RequestRec. So it checks isa() and finds that the first entry matches. It
should now return 'Apache::RequestIO', which AUTOLOAD loads and now when it
calls goto, it calls that method.
This snippet I've quoted earlier shows that method_lookup returns
'Apache::RequestIO'
perl -MModPerl::MethodLookup -le '\
package Apache::RequestRec; sub new { bless {}, shift }; \
package My::Request; @ISA = qw(Apache::RequestRec); \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj); \
print $hint'
To use method 'print' add:
use Apache::RequestIO ();
What do you see different?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Freitag, 13. Februar 2004 23:56 schrieb Stas Bekman:
> I've extended lookup_method to support sub-classed objects. which
> simplifies the usage. It's now committed. Here is a test:
>
> perl -MModPerl::MethodLookup -le '\
> package Apache::RequestRec; sub new { bless {}, shift }; \
> package My::Request; @ISA = qw(Apache::RequestRec); \
> package main; my $obj = My::Request->new(); \
> my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj);
> \ print $hint'
> To use method 'print' add:
> use Apache::RequestIO ();
>
> So EazyLife.pm, including fixes for your previous comments, looks like:
>
It works better, but not right. It has the same problems as the last one, but
the other way around ;-)
On my first test I found out that it is incredible slow. So iI move the
return if $AUTOLOAD =~ /$skip/;
line before the lookup_method. That is not right ever, your way looks much
better, but it was so slow. Perhaps other ideas are around.
The second problem is if I have a class that inherits from another class with
splitted functions like Apache::RequestRec.
package xxx;
@ISA='Apache::RequestRec';
sub new { bless $_[1], $_[0] }
sub handler : method {
my ( $class, $rec ) = @_;
xxx->new( $rec )->print('hello world');
}
then AUTOLOAD is called and found out, that Apache::RequestRec is the
superclass of xxx and that Apache::RequestIO must be loaded. We require
Apache::RequestRec and then goto subroutine xxx::print. That is an endless
loop, since it calls AUTOLOAD to find out about xxx::print. In this case we
must call Apache::RequestRec::print, but we do not know about it we only know
Apache::RequestIO.
> package ModPerl::EazyLife;
>
> use ModPerl::MethodLookup ();
> use Carp;
>
> my @avail_modules = ModPerl::MethodLookup::avail_modules();
> push @avail_modules, 'Apache'; # XXX: may go away
> my $skip = qr|(::)?DESTROY$|;
> for my $module (@avail_modules) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> if (@modules) {
> eval "require $_" for @modules;
> goto &$AUTOLOAD;
> }
> else {
> return if $AUTOLOAD =~ /$skip/;
> croak $hint || "Can't find $AUTOLOAD";
> }
> };
> }
>
> 1;
>
> You need to update your cvs and rebuild (because of the changes in the
> autogenerated MethodLookup.pm module).
>
Have a nice day.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
I've extended lookup_method to support sub-classed objects. which simplifies
the usage. It's now committed. Here is a test:
perl -MModPerl::MethodLookup -le '\
package Apache::RequestRec; sub new { bless {}, shift }; \
package My::Request; @ISA = qw(Apache::RequestRec); \
package main; my $obj = My::Request->new(); \
my($hint, @modules) = ModPerl::MethodLookup::lookup_method("print", $obj); \
print $hint'
To use method 'print' add:
use Apache::RequestIO ();
So EazyLife.pm, including fixes for your previous comments, looks like:
package ModPerl::EazyLife;
use ModPerl::MethodLookup ();
use Carp;
my @avail_modules = ModPerl::MethodLookup::avail_modules();
push @avail_modules, 'Apache'; # XXX: may go away
my $skip = qr|(::)?DESTROY$|;
for my $module (@avail_modules) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
if (@modules) {
eval "require $_" for @modules;
goto &$AUTOLOAD;
}
else {
return if $AUTOLOAD =~ /$skip/;
croak $hint || "Can't find $AUTOLOAD";
}
};
}
1;
You need to update your cvs and rebuild (because of the changes in the
autogenerated MethodLookup.pm module).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <st...@stason.org> writes:
>>>
>>>
>>>>Boris Zentner wrote:
>>>
>>>[...]
>>>
>>>
>>>>>Right, but using Apache::Request is not so uncommon.
>>>>
>>>>May be A-R can be fixed to use a proper inheritance?
>>>
>>>Sorry I haven't been paying attention to this thread.
>>>If by "proper inheritance" you mean, A-R should require
>>>Apache::RequestRec when it's running inside mp2, then
>>>*that* can be fixed easily.
>>
>>Boris was talking about Apache-Request objects not working properly with
>>AUTOLOAD (i.e. the functions lookup isn't getting propagated to AUTOLOAD).
>>
>>A-R should load only classes that it needs and never more.
>
>
> In mp2, Apache::RequestRec *is the base class* for A-R (A-R shouldn't
> have any AUTOLOAD methods). AFAICT that certainly fits the bill as
> being a necessity. How can a subclass be expected to work properly if
> its parent modules aren't available?
That's the thing we are trying to solve. You get $r (Apache::RequestRec
object), but none of the classes is loaded for you (because there are many
sub-packages that load parts of the API you can call on $r). So we are trying
the solution of defining Apache::RequestRec::AUTOLOAD which will resolve the
methods to modules containing them and load the modules behind the scenes as
they are needed. This is similar to AutoLoader but here we deal with XS modules.
So let's say you do:
sub handler {
my $r = shift;
$r->content_type('foo/bar');
w/o explicitly loading Apache::RequestRec. content_type will make its way to
Apache::RequestRec::AUTOLOAD, which will figure out that the method lives in
the Apache::RequestRec module and load it for you. Of couse if you preloaded
the module, everything will work w/o going through AUTOLOAD.
Now if $apr (Apache::Request object) is a sub-class of Apache::RequestRec and
the Apache::RequestRec module wasn't loaded so far. Calling
$apr->content_type('foo/bar');
should try to find Apache::Request::AUTOLOAD and since there is none, go up
@ISA and find Apache::RequestRec::AUTOLOAD, which will resolve the lookup and
load the missing module accomplishing the call.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Stefan Traby <st...@hello-penguin.com>.
On Fri, Feb 13, 2004 at 04:38:21PM -0500, Joe Schaefer wrote:
> In mp2, Apache::RequestRec *is the base class* for A-R (A-R shouldn't
> have any AUTOLOAD methods). AFAICT that certainly fits the bill as
> being a necessity. How can a subclass be expected to work properly if
> its parent modules aren't available?
Are you talking about the use-chain that is required?
I run happy with this: (If I got you wrong, sorry)
if (!defined $PApp::Apache2::_compiled) { eval do { local $/; <DATA> }; die if $@ } 1;
__DATA__
#line 5 "(PApp/Apache2.pm)"
package PApp::Apache2::Gateway;
use Apache2 ();
use Apache::Log ();
use Apache::RequestIO ();
use Apache::RequestRec ();
our @ISA = Apache::RequestRec::;
sub new {
bless $_[1], $_[0];
}
--
ciao -
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> >>Boris Zentner wrote:
> > [...]
> >
> >>>Right, but using Apache::Request is not so uncommon.
> >>
> >>May be A-R can be fixed to use a proper inheritance?
> > Sorry I haven't been paying attention to this thread.
> > If by "proper inheritance" you mean, A-R should require
> > Apache::RequestRec when it's running inside mp2, then
> > *that* can be fixed easily.
>
> Boris was talking about Apache-Request objects not working properly with
> AUTOLOAD (i.e. the functions lookup isn't getting propagated to AUTOLOAD).
>
> A-R should load only classes that it needs and never more.
In mp2, Apache::RequestRec *is the base class* for A-R (A-R shouldn't
have any AUTOLOAD methods). AFAICT that certainly fits the bill as
being a necessity. How can a subclass be expected to work properly if
its parent modules aren't available?
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Boris Zentner wrote:
>
>
> [...]
>
>
>>>Right, but using Apache::Request is not so uncommon.
>>
>>May be A-R can be fixed to use a proper inheritance?
>
>
> Sorry I haven't been paying attention to this thread.
> If by "proper inheritance" you mean, A-R should require
> Apache::RequestRec when it's running inside mp2, then
> *that* can be fixed easily.
Boris was talking about Apache-Request objects not working properly with
AUTOLOAD (i.e. the functions lookup isn't getting propagated to AUTOLOAD).
A-R should load only classes that it needs and never more.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Boris Zentner wrote:
[...]
> > Right, but using Apache::Request is not so uncommon.
>
> May be A-R can be fixed to use a proper inheritance?
Sorry I haven't been paying attention to this thread.
If by "proper inheritance" you mean, A-R should require
Apache::RequestRec when it's running inside mp2, then
*that* can be fixed easily.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Freitag, 13. Februar 2004 04:17 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>
>
> [...]
>
>
>>> 2. EazyLife can not know about my methods, so the option is guess and
>>>load all classes with methods that may satisfy me or ignore me. I dislike
>>>both and Apache::Request forwards everything unknown to the environ
>>>object, but it seems it looks what the object can ( untested ) so nothing
>>>is forwarded until the class is loaded.
>>
>>Well, may be your case is much more complicated than the average case, and
>>EazyLife could benefit a majority of users. And someone like you will have
>>to manually figure out which modules to load. Unless you have better idea.
>
>
> Right, but using Apache::Request is not so uncommon.
May be A-R can be fixed to use a proper inheritance?
> If the methods and functions are grouped in the classfiles then
> ModPerl::MethodLookup, EazyLife and a lot of hazzle including inherence work
> out of the box. Just to remark this a last time.
Yes, I remember that ;)
> I change the handle part a little
>
> # handle inheritance
> if (!@modules && $_[0] && ref( $_[0] ) ) {
> my($hint, @super_classes) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD);
> for (@super_classes) {
> push @modules, $_ if $_[0]->isa($_);
> }
Ooops, of course it's $_[0] and not $AUTOLOAD that's the object ;) Thanks for
the fix.
> But even then, it will not work. print seems a good startingpoint. Again from
> my example:
>
> lookup_method find some possible superclasses for SuperRequestRec.
>
> Apache::Filter and
> Apache::RequestIO.
>
> But the superclass for SuperRequestRec is Apache::RequestRec.
Ah, right. We are after the second argument (Apache::RequestRec), not the
first one (Apache::RequestIO).
I'll get back to you with a proper implementation.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Freitag, 13. Februar 2004 04:17 schrieb Stas Bekman:
> Boris Zentner wrote:
[...]
> >
> > 2. EazyLife can not know about my methods, so the option is guess and
> > load all classes with methods that may satisfy me or ignore me. I dislike
> > both and Apache::Request forwards everything unknown to the environ
> > object, but it seems it looks what the object can ( untested ) so nothing
> > is forwarded until the class is loaded.
>
> Well, may be your case is much more complicated than the average case, and
> EazyLife could benefit a majority of users. And someone like you will have
> to manually figure out which modules to load. Unless you have better idea.
Right, but using Apache::Request is not so uncommon.
If the methods and functions are grouped in the classfiles then
ModPerl::MethodLookup, EazyLife and a lot of hazzle including inherence work
out of the box. Just to remark this a last time.
>
> > Back to EazyLife:
> > It calls the AUTOLOAD function and in my case it is the right one. But if
> > My class is a new one ( one that is not part of mod_perl ) then
> > ModPerl::MethodLookup simply find nothing and dies.
> >
> > suppose this ( untested and useless ) example:
> >
> > package SuperRequestRec;
> > our @ISA = qw!Apache::RequestRec!;
> > sub new {
> > my $class = shift;
> > return bless shift, $class;
> > }
> > 1;
> >
> > sub handler :method {
> > my ( $c, $r ) = @_;
> > my $sr = SuperRequestRec->new( $r );
> > $sr->print("Hi");
> > return DONE;
> > }
> >
> > see this line from EazyLife.pm
> >
> > ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
> >
> > $AUTOLOAD may be SuperRequestRec::print
> >
> > and $_[0] is a reference to SuperRequestRec.
>
> I see what you mean. Try to patch it to try first:
>
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
> and if it fails:
>
> ModPerl::MethodLookup::lookup_method($AUTOLOAD);
>
> The second argument (@_) is optional to help resolve the situation when
> there is more than one class with the same method. For example:
>
> % perl -MApache2 -MModPerl::MethodLookup -e print_method new
> There is more than one class with method 'new'
> try one of:
> use APR::NetLib ();
> use APR::UUID ();
> use APR::Bucket ();
> use APR::Pool ();
> use Apache::RequestUtil ();
> use APR::ThreadMutex ();
> use APR::Brigade ();
> %
> % perl -MApache2 -MModPerl::MethodLookup -e print_method new
> Apache::RequestRec
>
> To use method 'new' add:
> use Apache::RequestUtil ();
>
> So how about this (it's untested):
>
> ----------------------------------
> package EazyLife;
>
> use ModPerl::MethodLookup ();
>
> for my $module (ModPerl::MethodLookup::avail_modules()) {
> *{"$module\::AUTOLOAD"} = sub {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> # handle inheritance
> unless (@modules) {
> my($hint, @super_classes) =
> ModPerl::MethodLookup::lookup_method($AUTOLOAD);
> for (@super_classes) {
> push @modules, $_ if ref($AUTOLOAD) && $AUTOLOAD->isa($_);
> }
> }
I change the handle part a little
# handle inheritance
if (!@modules && $_[0] && ref( $_[0] ) ) {
my($hint, @super_classes) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD);
for (@super_classes) {
push @modules, $_ if $_[0]->isa($_);
}
But even then, it will not work. print seems a good startingpoint. Again from
my example:
lookup_method find some possible superclasses for SuperRequestRec.
Apache::Filter and
Apache::RequestIO.
But the superclass for SuperRequestRec is Apache::RequestRec.
>
> if (@modules) {
> eval "require $_" for @modules;
> goto &$AUTOLOAD;
> }
> else {
> die $hint;
> }
> };
> }
>
> 1;
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Donnerstag, 12. Februar 2004 18:49 schrieb Stas Bekman:
>
>>>The biggest drawback for me is whenever inherence comes into play it wont
>>>work. Method_lookup is a hack. It is nice to have, but it whould much
>>>better if it is not needed at all.
>>
>>Do you suggest that AUTOLOAD doesn't work with inheritance? Doesn't it call
>>the right AUTOLOAD function?
>
>
> Yes, AUTOLOAD has some drawbacks. During my testing I found two of them
> imediately.
>
> 1. You can not rely on ->can. If I have a object and ask $obj->can('print')
> The answer is yes it can print, or I do not know maybe we can load print try
> it! Thats odd. But not a mod_perl issue.
>
> 2. EazyLife can not know about my methods, so the option is guess and load
> all classes with methods that may satisfy me or ignore me. I dislike both and
> Apache::Request forwards everything unknown to the environ object, but it
> seems it looks what the object can ( untested ) so nothing is forwarded until
> the class is loaded.
Well, may be your case is much more complicated than the average case, and
EazyLife could benefit a majority of users. And someone like you will have to
manually figure out which modules to load. Unless you have better idea.
> Back to EazyLife:
> It calls the AUTOLOAD function and in my case it is the right one. But if My
> class is a new one ( one that is not part of mod_perl ) then
> ModPerl::MethodLookup simply find nothing and dies.
>
> suppose this ( untested and useless ) example:
>
> package SuperRequestRec;
> our @ISA = qw!Apache::RequestRec!;
> sub new {
> my $class = shift;
> return bless shift, $class;
> }
> 1;
>
> sub handler :method {
> my ( $c, $r ) = @_;
> my $sr = SuperRequestRec->new( $r );
> $sr->print("Hi");
> return DONE;
> }
>
> see this line from EazyLife.pm
>
> ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
>
> $AUTOLOAD may be SuperRequestRec::print
>
> and $_[0] is a reference to SuperRequestRec.
I see what you mean. Try to patch it to try first:
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
and if it fails:
ModPerl::MethodLookup::lookup_method($AUTOLOAD);
The second argument (@_) is optional to help resolve the situation when there
is more than one class with the same method. For example:
% perl -MApache2 -MModPerl::MethodLookup -e print_method new
There is more than one class with method 'new'
try one of:
use APR::NetLib ();
use APR::UUID ();
use APR::Bucket ();
use APR::Pool ();
use Apache::RequestUtil ();
use APR::ThreadMutex ();
use APR::Brigade ();
%
% perl -MApache2 -MModPerl::MethodLookup -e print_method new Apache::RequestRec
To use method 'new' add:
use Apache::RequestUtil ();
So how about this (it's untested):
----------------------------------
package EazyLife;
use ModPerl::MethodLookup ();
for my $module (ModPerl::MethodLookup::avail_modules()) {
*{"$module\::AUTOLOAD"} = sub {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
# handle inheritance
unless (@modules) {
my($hint, @super_classes) =
ModPerl::MethodLookup::lookup_method($AUTOLOAD);
for (@super_classes) {
push @modules, $_ if ref($AUTOLOAD) && $AUTOLOAD->isa($_);
}
}
if (@modules) {
eval "require $_" for @modules;
goto &$AUTOLOAD;
}
else {
die $hint;
}
};
}
1;
----------------------------------
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Donnerstag, 12. Februar 2004 18:49 schrieb Stas Bekman:
> > The biggest drawback for me is whenever inherence comes into play it wont
> > work. Method_lookup is a hack. It is nice to have, but it whould much
> > better if it is not needed at all.
>
> Do you suggest that AUTOLOAD doesn't work with inheritance? Doesn't it call
> the right AUTOLOAD function?
Yes, AUTOLOAD has some drawbacks. During my testing I found two of them
imediately.
1. You can not rely on ->can. If I have a object and ask $obj->can('print')
The answer is yes it can print, or I do not know maybe we can load print try
it! Thats odd. But not a mod_perl issue.
2. EazyLife can not know about my methods, so the option is guess and load
all classes with methods that may satisfy me or ignore me. I dislike both and
Apache::Request forwards everything unknown to the environ object, but it
seems it looks what the object can ( untested ) so nothing is forwarded until
the class is loaded.
Back to EazyLife:
It calls the AUTOLOAD function and in my case it is the right one. But if My
class is a new one ( one that is not part of mod_perl ) then
ModPerl::MethodLookup simply find nothing and dies.
suppose this ( untested and useless ) example:
package SuperRequestRec;
our @ISA = qw!Apache::RequestRec!;
sub new {
my $class = shift;
return bless shift, $class;
}
1;
sub handler :method {
my ( $c, $r ) = @_;
my $sr = SuperRequestRec->new( $r );
$sr->print("Hi");
return DONE;
}
see this line from EazyLife.pm
ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
$AUTOLOAD may be SuperRequestRec::print
and $_[0] is a reference to SuperRequestRec.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> Am Mittwoch, 11. Februar 2004 02:16 schrieb Stas Bekman:
>
>>>So I think Apache::Request use a kind of ->can to check for a method
>>>before it forwards it. This makes the EazyLife option useless for me. (
>>>Or I have to support a kind of autoloader or preloader for my class, but
>>>that make it useless too. )
>>
>>I think not. headers_in called on $r should have AUTOLOADED
>>Apache::RequestRec. Now since you call it on Apache::Request::PageKit for
>>some reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably
>>a problem in either Apache::Request::PageKit or Apache::Request, with
>>inheritance gone wrong.
>>
>>Does it work for you if you use a pure modperl handler/registry script?
>
>
> Yes, it works. But it turns out to be _very_ terrible in my case. I vote for
> removing the EazyLife patch or make it a config option ( in httpd.conf ).
> Perhaps there are better solutions.
>
> I encount zilions of ::DESTROY searches. But I can not install a ::DESTROY sub
> for every module, it may have it's own one.
That can be handled. As in:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
> The biggest drawback for me is whenever inherence comes into play it wont
> work. Method_lookup is a hack. It is nice to have, but it whould much better
> if it is not needed at all.
Do you suggest that AUTOLOAD doesn't work with inheritance? Doesn't it call
the right AUTOLOAD function?
> The end of my testing was that I was forced to add a AUTOLOAD method for my
> class that fakes my environment and make a call to the RequestRec object to
> make it work.
>
> The die statement in EasyLife.pm should include $AUTOLOAD and @_ for
> debugging, since $hint was most of the time ''.
Sure, that can be handled too.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
Am Mittwoch, 11. Februar 2004 02:16 schrieb Stas Bekman:
> > So I think Apache::Request use a kind of ->can to check for a method
> > before it forwards it. This makes the EazyLife option useless for me. (
> > Or I have to support a kind of autoloader or preloader for my class, but
> > that make it useless too. )
>
> I think not. headers_in called on $r should have AUTOLOADED
> Apache::RequestRec. Now since you call it on Apache::Request::PageKit for
> some reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably
> a problem in either Apache::Request::PageKit or Apache::Request, with
> inheritance gone wrong.
>
> Does it work for you if you use a pure modperl handler/registry script?
Yes, it works. But it turns out to be _very_ terrible in my case. I vote for
removing the EazyLife patch or make it a config option ( in httpd.conf ).
Perhaps there are better solutions.
I encount zilions of ::DESTROY searches. But I can not install a ::DESTROY sub
for every module, it may have it's own one.
The biggest drawback for me is whenever inherence comes into play it wont
work. Method_lookup is a hack. It is nice to have, but it whould much better
if it is not needed at all.
The end of my testing was that I was forced to add a AUTOLOAD method for my
class that fakes my environment and make a call to the RequestRec object to
make it work.
The die statement in EasyLife.pm should include $AUTOLOAD and @_ for
debugging, since $hint was most of the time ''.
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi Stas,
>
> I tried it and unfortunely it did not work for me. I downloaded the CVS
> version of modperl-2 and installed your patch.
Thanks for testing it, Boris.
> As next step I removed all MP2 use directives.
>
> #use Apache::RequestRec ();
> #use Apache::RequestIO ();
> #use Apache::ServerUtil ();
> #use Apache::RequestUtil ();
> #use Apache::Util ();
> #use APR::Date ();
>
> This is the result.
>
> waiting 60 seconds for server to start: ..[Tue Feb 10 17:57:49 2004] [warn]
> Syntax error
> at /home/ptest2/src/Apache-PageKit-2.12-5/t/conf/extra.last.conf:15 Can't
> locate object method "server" via package "Apache"
> at /home/ptest2/src/Apache-PageKit-2.12-5/blib/lib/Apache/PageKit.pm line
> 113.
>
> Now I uncomment
>
> use Apache::ServerUtil ();
>
> to get access to the server method.
EazyLife works for objects $r, $s, etc. I don't remember we have covered class
methods, but that is fixable. The reason the autoload didn't work here, is
that there is no Apache module, and therefore EazyLife didn't add
Apache::AUTOLOAD. Depending on the outcomings of the Apache:: namespace
extinction process, we may add it manually if it survives.
> Now my error message is
>
> Can't locate auto/Apache/Request/PageKit/headers_in.al
>
> So I think Apache::Request use a kind of ->can to check for a method before it
> forwards it. This makes the EazyLife option useless for me. ( Or I have to
> support a kind of autoloader or preloader for my class, but that make it
> useless too. )
I think not. headers_in called on $r should have AUTOLOADED
Apache::RequestRec. Now since you call it on Apache::Request::PageKit for some
reason it doesn't reach Apache::RequestRec::AUTOLOAD. That's probably a
problem in either Apache::Request::PageKit or Apache::Request, with
inheritance gone wrong.
Does it work for you if you use a pure modperl handler/registry script?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost Apache:: usage?)
Posted by Boris Zentner <bz...@2bz.de>.
Hi Stas,
I tried it and unfortunely it did not work for me. I downloaded the CVS
version of modperl-2 and installed your patch.
As next step I removed all MP2 use directives.
#use Apache::RequestRec ();
#use Apache::RequestIO ();
#use Apache::ServerUtil ();
#use Apache::RequestUtil ();
#use Apache::Util ();
#use APR::Date ();
This is the result.
waiting 60 seconds for server to start: ..[Tue Feb 10 17:57:49 2004] [warn]
Syntax error
at /home/ptest2/src/Apache-PageKit-2.12-5/t/conf/extra.last.conf:15 Can't
locate object method "server" via package "Apache"
at /home/ptest2/src/Apache-PageKit-2.12-5/blib/lib/Apache/PageKit.pm line
113.
Now I uncomment
use Apache::ServerUtil ();
to get access to the server method.
Now my error message is
Can't locate auto/Apache/Request/PageKit/headers_in.al
So I think Apache::Request use a kind of ->can to check for a method before it
forwards it. This makes the EazyLife option useless for me. ( Or I have to
support a kind of autoloader or preloader for my class, but that make it
useless too. )
Am Montag, 9. Februar 2004 19:38 schrieb Stas Bekman:
> Stas Bekman wrote:
> > Perrin Harkins wrote:
> >> On Tue, 2004-01-20 at 16:17, Stas Bekman wrote:
> >>> I now more or less have an idea on how to solve the code usage problem.
> >>
> >> Great!
> >
> > My idea is replace UNIVERSAL::AUTOLOAD with AUTOLOAD for each class that
> > contains objects, so when the method is called on that object it'll do
> > just that:
> > http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
>
> [...]
>
> OK, here it is. Please give it a try:
>
> Index: lib/ModPerl/WrapXS.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/lib/ModPerl/WrapXS.pm,v
> retrieving revision 1.64
> diff -u -u -r1.64 WrapXS.pm
> --- lib/ModPerl/WrapXS.pm 31 Jan 2004 10:06:59 -0000 1.64
> +++ lib/ModPerl/WrapXS.pm 9 Feb 2004 18:36:02 -0000
> @@ -786,6 +786,16 @@
> return keys %$methods;
> }
>
> +sub avail_modules {
> + my %modules = ();
> + for my $method (keys %$methods) {
> + for my $item ( @{ $methods->{$method} }) {
> + $modules{$item->[MODULE]}++;
> + }
> + }
> + return keys %modules;
> +}
> +
> sub preload_all_modules {
> _get_modules() unless $modules;
> eval "require $_" for keys %$modules;
> Index: src/modules/perl/mod_perl.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
> retrieving revision 1.206
> diff -u -u -r1.206 mod_perl.c
> --- src/modules/perl/mod_perl.c 10 Jan 2004 05:01:04 -0000 1.206
> +++ src/modules/perl/mod_perl.c 9 Feb 2004 18:36:02 -0000
> @@ -246,6 +246,10 @@
> av_push(GvAV(PL_incgv),
> newSVpv(ap_server_root_relative(p, "lib/perl"), 0));
> #endif /* MP_COMPAT_1X */
> +
> + /* AUTOLOADs */
> + /* XXX: consider adding a config flag not to preload this module */
> + modperl_require_module(aTHX_ "ModPerl::EazyLife", TRUE);
>
> if (!modperl_config_apply_PerlRequire(s, scfg, perl, p)) {
> exit(1);
> --- /dev/null 1969-12-31 16:00:00.000000000 -0800
> +++ lib/ModPerl/EazyLife.pm 2004-02-03 08:00:34.000000000 -0800
> @@ -0,0 +1,19 @@
> +package EazyLife;
> +
> +use ModPerl::MethodLookup ();
> +
> +for my $module (ModPerl::MethodLookup::avail_modules()) {
> + *{"$module\::AUTOLOAD"} = sub {
> + my($hint, @modules) =
> + ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
> + if (@modules) {
> + eval "require $_" for @modules;
> + goto &$AUTOLOAD;
> + }
> + else {
> + die $hint;
> + }
> + };
> +}
> +
> +1;
>
>
> ______________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[mp2 patch] ModPerl/EazyLife.pm (was Re: [mp2] killing the ghost
Apache:: usage?)
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Perrin Harkins wrote:
>
>> On Tue, 2004-01-20 at 16:17, Stas Bekman wrote:
>>
>>> I now more or less have an idea on how to solve the code usage problem.
>>
>>
>>
>> Great!
>
>
> My idea is replace UNIVERSAL::AUTOLOAD with AUTOLOAD for each class that
> contains objects, so when the method is called on that object it'll do
> just that:
> http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
[...]
OK, here it is. Please give it a try:
Index: lib/ModPerl/WrapXS.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/WrapXS.pm,v
retrieving revision 1.64
diff -u -u -r1.64 WrapXS.pm
--- lib/ModPerl/WrapXS.pm 31 Jan 2004 10:06:59 -0000 1.64
+++ lib/ModPerl/WrapXS.pm 9 Feb 2004 18:36:02 -0000
@@ -786,6 +786,16 @@
return keys %$methods;
}
+sub avail_modules {
+ my %modules = ();
+ for my $method (keys %$methods) {
+ for my $item ( @{ $methods->{$method} }) {
+ $modules{$item->[MODULE]}++;
+ }
+ }
+ return keys %modules;
+}
+
sub preload_all_modules {
_get_modules() unless $modules;
eval "require $_" for keys %$modules;
Index: src/modules/perl/mod_perl.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.206
diff -u -u -r1.206 mod_perl.c
--- src/modules/perl/mod_perl.c 10 Jan 2004 05:01:04 -0000 1.206
+++ src/modules/perl/mod_perl.c 9 Feb 2004 18:36:02 -0000
@@ -246,6 +246,10 @@
av_push(GvAV(PL_incgv),
newSVpv(ap_server_root_relative(p, "lib/perl"), 0));
#endif /* MP_COMPAT_1X */
+
+ /* AUTOLOADs */
+ /* XXX: consider adding a config flag not to preload this module */
+ modperl_require_module(aTHX_ "ModPerl::EazyLife", TRUE);
if (!modperl_config_apply_PerlRequire(s, scfg, perl, p)) {
exit(1);
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ lib/ModPerl/EazyLife.pm 2004-02-03 08:00:34.000000000 -0800
@@ -0,0 +1,19 @@
+package EazyLife;
+
+use ModPerl::MethodLookup ();
+
+for my $module (ModPerl::MethodLookup::avail_modules()) {
+ *{"$module\::AUTOLOAD"} = sub {
+ my($hint, @modules) =
+ ModPerl::MethodLookup::lookup_method($AUTOLOAD, @_);
+ if (@modules) {
+ eval "require $_" for @modules;
+ goto &$AUTOLOAD;
+ }
+ else {
+ die $hint;
+ }
+ };
+}
+
+1;
______________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
> package ModPerl::EasyLife;
> use ModPerl::MethodLookup;
> sub my_AUTOLOAD {
> my($hint, @modules) =
> ModPerl::MethodLookup::lookup_method($UNIVERSAL::AUTOLOAD, @_);
copy-n-paste typo: s/UNIVERSAL:://; of course
> if (@modules) {
> eval "require $_" for @modules;
> goto &$AUTOLOAD;
> }
> else {
> die $hint;
> }
> }
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Tue, 2004-01-20 at 16:17, Stas Bekman wrote:
>
>>I now more or less have an idea on how to solve the code usage problem.
>
>
> Great!
My idea is replace UNIVERSAL::AUTOLOAD with AUTOLOAD for each class that
contains objects, so when the method is called on that object it'll do just that:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
ModPerl::MethodLookup::lookup_method is smart enough to figure out that if
there are 3 modules that contain method read() and the object is blessed into
Apache::RequestRec it'll load Apache::RequestIO and not the other 2 modules
(APR::Bucket and Apache::Filter).
So essentially when mod_perl boots it will load a helper module
ModPerl::EasyLife containing:
package ModPerl::EasyLife;
use ModPerl::MethodLookup;
sub my_AUTOLOAD {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($UNIVERSAL::AUTOLOAD, @_);
if (@modules) {
eval "require $_" for @modules;
goto &$AUTOLOAD;
}
else {
die $hint;
}
}
*Apache::RequestRec::AUTOLOAD = *my_AUTOLOAD;
*Apache::ServerRec::AUTOLOAD = *my_AUTOLOAD;
*Apache::Filter::AUTOLOAD = *my_AUTOLOAD;
etc... for each class that contains object methods
in fact it'll automatically figure out the list of modules it needs to install
AUTOLOAD for via the same old ModPerl::MethodLookup, and not hardcoded like in
the above example.
So there will be no run-time overhead to figure out whether we have already
installed AUTOLOAD or not, they will be installed by definition.
Also there should be an option to disable AUTOLOADing. This is for CPAN
authors who will need to figure out which modules to load, to give their users
the best performance in terms of better memory sharing.
>>What I don't have clear yet is the docs issue. Certainly you want to find the
>>method of class Apache::RequestRec in its the right manpage
>>(Apache::RequestRec). But $r has about 150 methods.
>
>
> Yes, this is a trickier question. Looking at other big projects, it
> seems like DBI and CGI have chosen the "one huge page" approach. This
> still works fairly well since they make careful use of headings in the
> POD. Ideally, I'd certainly like to see all of the methods available
> through $r documented in Apache::RequestRec, even if it does make the
> page big. Any idea if it would be bigger than DBI or not?
I don't know. There are about 150 methods and the moment there are only
skeletons for most. Once you fill them in with more text and examples it'll be
enourmous. Just the TOC is going to be huge. Or it might just work.
If we eliminate the other manpages, I guess people can still use
ModPerl::MethodLookup to find out whether they need to preload
Apache::RequestIO, etc. Or we could mention for each method entry which
physical .so object it lives in.
>>So my idea was to list all Apache::RequestRec methods in the
>>Apache::RequestRec manpage, but have the bodies of most of them spread across
>>Apache::RequestIO, etc, just like it is now. That's if you use the web
>>interface. It won't quite work for 'perldoc'.
>
>
> That would be my second choice if the one page is unmanageable. Which
> part doesn't work with perldoc? Just the actual links?
Yup, xrefs to other manpages.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-01-20 at 16:17, Stas Bekman wrote:
> I now more or less have an idea on how to solve the code usage problem.
Great!
> What I don't have clear yet is the docs issue. Certainly you want to find the
> method of class Apache::RequestRec in its the right manpage
> (Apache::RequestRec). But $r has about 150 methods.
Yes, this is a trickier question. Looking at other big projects, it
seems like DBI and CGI have chosen the "one huge page" approach. This
still works fairly well since they make careful use of headings in the
POD. Ideally, I'd certainly like to see all of the methods available
through $r documented in Apache::RequestRec, even if it does make the
page big. Any idea if it would be bigger than DBI or not?
> So my idea was to list all Apache::RequestRec methods in the
> Apache::RequestRec manpage, but have the bodies of most of them spread across
> Apache::RequestIO, etc, just like it is now. That's if you use the web
> interface. It won't quite work for 'perldoc'.
That would be my second choice if the one page is unmanageable. Which
part doesn't work with perldoc? Just the actual links?
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Tue, 2004-01-20 at 16:02, Boris Zentner wrote:
>
>>just to clarify it, I mean it like Perrin but not that stong, I have no
>>problem to load a package to use it. My problem is to load package bar to
>>fill methods for package foo.
>
>
> When someone passes your handler a live $r object, you shouldn't have to
> load that module to use it, since the code that is passing you $r must
> have already loaded the class in order to make a $r object. On the
> other hand, if you need to actually call a method like
> Apache::RequestRec->foo() then you should explicitly load that class.
cool. now we have an agreement between Boris and Perrin ;)
I now more or less have an idea on how to solve the code usage problem.
What I don't have clear yet is the docs issue. Certainly you want to find the
method of class Apache::RequestRec in its the right manpage
(Apache::RequestRec). But $r has about 150 methods. Having them all in one
page is very impractical. Just like you never do 'perldoc perlfunc', but
'perldoc -f function', you won't want to load an 1MB html page for
Apache/RequestRec.pod. Currently the split on the code level also nicely
groups the methods into several manpages by their categories, making it easier
to per-use and comprehend.
So my idea was to list all Apache::RequestRec methods in the
Apache::RequestRec manpage, but have the bodies of most of them spread across
Apache::RequestIO, etc, just like it is now. That's if you use the web
interface. It won't quite work for 'perldoc'.
So now that you know what the problem is, please tell us your ideas on how to
approach that.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-01-20 at 16:02, Boris Zentner wrote:
> just to clarify it, I mean it like Perrin but not that stong, I have no
> problem to load a package to use it. My problem is to load package bar to
> fill methods for package foo.
When someone passes your handler a live $r object, you shouldn't have to
load that module to use it, since the code that is passing you $r must
have already loaded the class in order to make a $r object. On the
other hand, if you need to actually call a method like
Apache::RequestRec->foo() then you should explicitly load that class.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
HI,
just to clarify it, I mean it like Perrin but not that stong, I have no
problem to load a package to use it. My problem is to load package bar to
fill methods for package foo.
The autoload stuff is only needed for the larger magic classes like Request*
and Server*. That is my view and it is inbetween your and perrin's, but
largely closer to perrin.
Am Dienstag, 20. Januar 2004 21:50 schrieb Stas Bekman:
> Perrin Harkins wrote:
> > On Tue, 2004-01-20 at 15:13, Stas Bekman wrote:
> >>That's not what Perrin is talking about I think.
> >
> > No, it is. Boris and I are saying the same thing.
>
> No exactly. Boris gave an example on how he sees things should be. That
> example included:
>
> use Apache::RequestRec;
>
> You advocate that it shouldn't be there. So?
>
> > I want all of the objects passed to users to AUTOLOAD their methods. I
> > just don't know what most of them are yet, since I haven't done any work
> > with mp2.
>
> I understood that.
>
>
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Tue, 2004-01-20 at 15:13, Stas Bekman wrote:
>
>>That's not what Perrin is talking about I think.
>
>
> No, it is. Boris and I are saying the same thing.
No exactly. Boris gave an example on how he sees things should be. That
example included:
use Apache::RequestRec;
You advocate that it shouldn't be there. So?
> I want all of the objects passed to users to AUTOLOAD their methods. I
> just don't know what most of them are yet, since I haven't done any work
> with mp2.
I understood that.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-01-20 at 15:13, Stas Bekman wrote:
> That's not what Perrin is talking about I think.
No, it is. Boris and I are saying the same thing.
> So you do suggest that a user
> need to load 'Apache::RequestRec' to get $r methods?
I don't think either of us meant to suggest that.
> So if I understand
> Perrin's vision, that code should work with:
>
> use APR::Table;
> sub handler : method {
> my $r = shift;
> $r->print('xx');
> my $t = $r->notes;
> $t->set('foo');
> }
Yes, except you should not need to load APR::Table.
> my problem is why $r is magical, but not $t.
I want all of the objects passed to users to AUTOLOAD their methods. I
just don't know what most of them are yet, since I haven't done any work
with mp2.
> Why inconsistency? if you didn't
> create $t, you shouldn't need to load APR::Table, it should be there for you,
> just like with $r.
Exactly, this is what Boris and I both want.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Dienstag, 20. Januar 2004 19:51 schrieb Perrin Harkins:
>
>>>What about the other 200+
>>>methods in about 30 modules? People will still need to figure out what to
>>>load to use these (e.g. Apache::URI's methods don't necessarily work with
>>>$r, so how do you know that you need to load that module?)
>>
>>I think it's fine for people to explicitly load Apache::URI in order to
>>call methods like Apache::URI->foo(), but not for methods that are
>>called through $r, or $s, or any other object that the user gets passed.
>>
>>
>>> Where do you install that
>>>AUTOLOAD on functions or modules which aren't $r or $s operators?
>>
>>I don't want to AUTOLOAD anything that isn't called through one of
>>those.
>
>
> This is exactly what I try to say for the last x mails. Whenever I act with a
> object of type x, I do a 'use x;'. Here a example I can use print without
> RequestIO but sure I must load APR::Table to use method set.
>
> use APR::Table;
> use Apache::RequestRec;
> sub handler : method {
> my $r = shift;
> $r->print('xx');
> my $t = $r->notes;
> $t->set('foo');
> }
That's not what Perrin is talking about I think. So you do suggest that a user
need to load 'Apache::RequestRec' to get $r methods?
Perrin suggests that you don't need to load anything from your code, because
you already receive $r, so the methods should be there already. Compared to
the situation where you create the object by yourself. So if I understand
Perrin's vision, that code should work with:
use APR::Table;
sub handler : method {
my $r = shift;
$r->print('xx');
my $t = $r->notes;
$t->set('foo');
}
my problem is why $r is magical, but not $t. Why inconsistency? if you didn't
create $t, you shouldn't need to load APR::Table, it should be there for you,
just like with $r.
So as you can see your and Perrin's views aren't exactly the same. Please
correct me if I'm wrong.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Dienstag, 20. Januar 2004 19:51 schrieb Perrin Harkins:
> > What about the other 200+
> > methods in about 30 modules? People will still need to figure out what to
> > load to use these (e.g. Apache::URI's methods don't necessarily work with
> > $r, so how do you know that you need to load that module?)
>
> I think it's fine for people to explicitly load Apache::URI in order to
> call methods like Apache::URI->foo(), but not for methods that are
> called through $r, or $s, or any other object that the user gets passed.
>
> > Where do you install that
> > AUTOLOAD on functions or modules which aren't $r or $s operators?
>
> I don't want to AUTOLOAD anything that isn't called through one of
> those.
This is exactly what I try to say for the last x mails. Whenever I act with a
object of type x, I do a 'use x;'. Here a example I can use print without
RequestIO but sure I must load APR::Table to use method set.
use APR::Table;
use Apache::RequestRec;
sub handler : method {
my $r = shift;
$r->print('xx');
my $t = $r->notes;
$t->set('foo');
}
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Tue, 2004-01-20 at 15:09, Stas Bekman wrote:
>
>>>Good. Do you think there should be a separate module for this, that
>>>just acts a shell for $r and AUTOLOADs other things? That would avoid
>>>loading Apache::RequestRec unless it is needed. Apache::RequestHandle
>>>maybe?
>>
>>You don't necessarily need a module for that. All you want to do is to install
>>
>>sub Apache::RequestRec::AUTOLOAD, with a few lines of code.
>
>
> Why do it in a strange way? Why not simply have a normal module? It's
> easier to maintain if things live in the most obvious place.
It's easier when there is one or two objects. I repeat that in mp2 there are
*many* objects, and adding many new modules just to install an AUTOLOAD module
which is going to be exactly the same with is not going to make things easier
to maintain.
Really, it should have been UNIVERSAL::AUTOLOAD that will handle them all at
once as you can see from the ModPerl::MethodLookup manpage. And it works for
most phases, but the startup ones, where it mysteriously segfaults.
>>See, this is your "problem" - mp2 is much more than $r and $s. But you want to
>>fix only those because you don't know about the others. We here try to have it
>>right and homogenious for the whole API. So people who will want to use mp2
>>just to write filters won't say, why $r is easy but $f is not?
>
>
> Good question. Why wouldn't we do the same thing with $f, and any
> others that I don't know about?
We would. And that's exactly why I didn't stop at the suggestion of yours for
$r-problem.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-01-20 at 15:09, Stas Bekman wrote:
> > Good. Do you think there should be a separate module for this, that
> > just acts a shell for $r and AUTOLOADs other things? That would avoid
> > loading Apache::RequestRec unless it is needed. Apache::RequestHandle
> > maybe?
>
> You don't necessarily need a module for that. All you want to do is to install
>
> sub Apache::RequestRec::AUTOLOAD, with a few lines of code.
Why do it in a strange way? Why not simply have a normal module? It's
easier to maintain if things live in the most obvious place.
> That's exactly the problem. There are many cases where we don't pass $r
> explicitly but you can always get it via $r->server or $f->server, or
> Apache->server. So it's quite possible that the only solution is to always
> have this hook/wrapper preloaded.
These should all return exactly the same thing as when you get passed
$r, so they will all know how to AUTOLOAD.
> BTW, inside a filter you can do $filter->r. Do you suggest that we change that
> accessor to install the wrapper too?
See above.
> Do you see what I meant by saying that you need to look beyond the mp1-like $r
> usage.
Not really. Sorry.
> But there are many other objects returned by mp2 API, beyong $r, $s and $c.
> what about them?
They should all work the same way. Users should never have to
explicitly load a module just to allow them to call a method on an
object they already have.
> See, this is your "problem" - mp2 is much more than $r and $s. But you want to
> fix only those because you don't know about the others. We here try to have it
> right and homogenious for the whole API. So people who will want to use mp2
> just to write filters won't say, why $r is easy but $f is not?
Good question. Why wouldn't we do the same thing with $f, and any
others that I don't know about?
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
>>I understand that you will want to preload that module that knows how to
>>AUTOLOAD the others on every handler that gets $r passed. Which works for me.
>
>
> Good. Do you think there should be a separate module for this, that
> just acts a shell for $r and AUTOLOADs other things? That would avoid
> loading Apache::RequestRec unless it is needed. Apache::RequestHandle
> maybe?
You don't necessarily need a module for that. All you want to do is to install
sub Apache::RequestRec::AUTOLOAD, with a few lines of code.
it can live anywhere. We may have a special module (e.g. ModPerl::Controller
or something like that) which can have hooks to install this kind of things.
And will always loaded at the server startup and its hooked called from the C
code.
>>If you want to do the same thing for $s, besides the child_init/child_exist
>>hooks, none of the request hooks receives a server object. How do you know
>>when to load that wrapper for $s?
>
>
> How do we know if we should load the wrapper? We should always load it
> if we're going to give anyone $s, and it can be such a small class
> (Apache::ServerHandle?) that it won't add much to load it all the time.
That's exactly the problem. There are many cases where we don't pass $r
explicitly but you can always get it via $r->server or $f->server, or
Apache->server. So it's quite possible that the only solution is to always
have this hook/wrapper preloaded.
BTW, inside a filter you can do $filter->r. Do you suggest that we change that
accessor to install the wrapper too? That would be ineffective to do that on
every call. So we end up with needing to preload the $r wrapper no matter
what, just like $s.
Do you see what I meant by saying that you need to look beyond the mp1-like $r
usage.
>>What about the other 200+
>>methods in about 30 modules? People will still need to figure out what to load
>>to use these (e.g. Apache::URI's methods don't necessarily work with $r, so
>>how do you know that you need to load that module?)
>
>
> I think it's fine for people to explicitly load Apache::URI in order to
> call methods like Apache::URI->foo(), but not for methods that are
> called through $r, or $s, or any other object that the user gets passed.
But there are many other objects returned by mp2 API, beyong $r, $s and $c.
what about them?
>> Where do you install that
>>AUTOLOAD on functions or modules which aren't $r or $s operators?
>
>
> I don't want to AUTOLOAD anything that isn't called through one of
> those.
See, this is your "problem" - mp2 is much more than $r and $s. But you want to
fix only those because you don't know about the others. We here try to have it
right and homogenious for the whole API. So people who will want to use mp2
just to write filters won't say, why $r is easy but $f is not?
> Think about it like this: $r and friends are the mod_perl API.
> Apache::RequestRec|IO|etc. are the implementation. If you look at
> things like DBI, there is a precedent for doing it the way I'm
> suggesting. DBI gives you a database handle, and deals with lots of
> AUTOLOADed stuff behind the scenes. We advise people to put "use
> DBD::Oracle" or whatever they are using in startup.pl as a tuning
> measure. This would work the same way.
We have already agreed on that part I think. All I'm thinking about is the
'friends' part, which are a way too many, and some of them I don't even know
about yet.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-01-20 at 01:07, Stas Bekman wrote:
> Good thinking, Perrin. But you need to take it all the way through, because
> I'm afraid you need to look at the whole picture and not lock yourlself in the
> $r world.
You're right, I haven't looked at anything else yet.
> I understand that you will want to preload that module that knows how to
> AUTOLOAD the others on every handler that gets $r passed. Which works for me.
Good. Do you think there should be a separate module for this, that
just acts a shell for $r and AUTOLOADs other things? That would avoid
loading Apache::RequestRec unless it is needed. Apache::RequestHandle
maybe?
> If you want to do the same thing for $s, besides the child_init/child_exist
> hooks, none of the request hooks receives a server object. How do you know
> when to load that wrapper for $s?
How do we know if we should load the wrapper? We should always load it
if we're going to give anyone $s, and it can be such a small class
(Apache::ServerHandle?) that it won't add much to load it all the time.
> What about the other 200+
> methods in about 30 modules? People will still need to figure out what to load
> to use these (e.g. Apache::URI's methods don't necessarily work with $r, so
> how do you know that you need to load that module?)
I think it's fine for people to explicitly load Apache::URI in order to
call methods like Apache::URI->foo(), but not for methods that are
called through $r, or $s, or any other object that the user gets passed.
> Where do you install that
> AUTOLOAD on functions or modules which aren't $r or $s operators?
I don't want to AUTOLOAD anything that isn't called through one of
those.
Think about it like this: $r and friends are the mod_perl API.
Apache::RequestRec|IO|etc. are the implementation. If you look at
things like DBI, there is a precedent for doing it the way I'm
suggesting. DBI gives you a database handle, and deals with lots of
AUTOLOADed stuff behind the scenes. We advise people to put "use
DBD::Oracle" or whatever they are using in startup.pl as a tuning
measure. This would work the same way.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
[...]
> Let's step back for a minute. I am late to this party, since I haven't
> been working on the mp2 code at all or even doing much with it. Here's
> what it looks like to me, and please correct me if I'm wrong:
>
> Because of the way the C API is laid out, it made sense to put these
> methods into different modules that parallel things in the C API.
> However, there was still a desire to have all of these methods available
> through $r. The solution chosen was to have other modules define things
> in the Apache::RequestRec namespace. I think this is the wrong solution
> because it confuses people about what they are using and what needs to
> be loaded explicitly.
>
> The other force at work here is the desire to not load things that are
> not needed because of memory concerns. Perl has a standard way of
> handling delayed loading, which is AUTOLOAD and the AutoLoader/autosplit
> technique. The concern with that is that $r is currently an instance of
> a class that is not always loaded, and that delayed loading defeats the
> memory efficiency of preloading.
>
> Here is what I suggest:
>
> - Make $r an instance of a new class, something like
> Apache::RequestHandle, or else keep it in RequestRec but always load
> RequestRec.
>
> - Define an AUTOLOAD method in that class which can load other modules
> on demand when people call methods on $r.
>
> - Provide import groups that preload the AUTOLOADed functions, similar
> to what Josh said but still allowing AUTOLOADing of anything not
> preloaded. This would be almost identical to the CGI.pm pre-compile stuff.
>
> This would allow full backwards compatibility with the current API too,
> at least for everything called through $r.
Good thinking, Perrin. But you need to take it all the way through, because
I'm afraid you need to look at the whole picture and not lock yourlself in the
$r world.
Let's say we do what you propose (which makes a lot of sense to me) for $r and
its method containers Apache::Request*, Apache::Log, etc.
perl -MApache2 -MModPerl::MethodLookup -e print_object Apache::RequestRec |
grep Apache | wc -l
146
That covers 146 methods in about 10 modules. What about the other 250+ in 30+
modules?
I understand that you will want to preload that module that knows how to
AUTOLOAD the others on every handler that gets $r passed. Which works for me.
If you want to do the same thing for $s, besides the child_init/child_exist
hooks, none of the request hooks receives a server object. How do you know
when to load that wrapper for $s?
perl -MApache2 -MModPerl::MethodLookup -e print_object Apache::Server | grep
Apache | wc -l
31
That covers 31 more methods and I think 3 modules. What about the other 200+
methods in about 30 modules? People will still need to figure out what to load
to use these (e.g. Apache::URI's methods don't necessarily work with $r, so
how do you know that you need to load that module?) Where do you install that
AUTOLOAD on functions or modules which aren't $r or $s operators? In a
$SIG{__DIE__} handler or overriding GLOBAL::CORE::die, or in
UNIVERSAL::AUTOLOAD, which has a pack of its own troubles?
Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> but Apache::RequestUtil::is_initial_req expect an object blessed into
> Apache::RequestRec. So:
>
> $r->is_initial_req();
>
> is fine.
No, it's not. $r is not an instance of Apache::RequestUtil, so calling
methods on it that are defined in Apache::RequestUtil makes no sense.
This is what I'm objecting to. If Apache::RequestUtil were hidden and
didn't have to be explicitly loaded by the user, I would not have a
problem with this.
>> Huh? Isn't $r an instance of Apache::RequestRec? If not, what is it?
>
>
> It is. But you are confusing the name of the class 'Apache::RequestRec'
> with a module Apache/RequestRec.(pm|so). You can perfectly use $r w/o
> ever loading the module Apache/RequestRec.(pm|so).
Are you saying that $r is blessed into a class that may or not be
loaded? I think that's not a good idea. $r should always be an
instance of a real class. If you don't want to force Apache::RequestRec
to be loaded, then make $r an instance of something else that will
always be loaded, like maybe a tiny class that exists just to autoload
the methods you call on it.
> Here is an example:
>
> package MyLog;
> use Apache::Log;
> use Apache::Const -compile => 'OK';
> sub handler {
> my $r = shift;
> $r->log_error("whatever");
> return Apache::OK;
> }
That looks totally wrong to me, unless $r is an instance of Apache::Log,
which I know it isn't in this case.
> Where would you install AUTOLOAD? In which class?
In Apache::RequestRec, or whatever (loaded) class $r is going to be.
Let's step back for a minute. I am late to this party, since I haven't
been working on the mp2 code at all or even doing much with it. Here's
what it looks like to me, and please correct me if I'm wrong:
Because of the way the C API is laid out, it made sense to put these
methods into different modules that parallel things in the C API.
However, there was still a desire to have all of these methods available
through $r. The solution chosen was to have other modules define things
in the Apache::RequestRec namespace. I think this is the wrong solution
because it confuses people about what they are using and what needs to
be loaded explicitly.
The other force at work here is the desire to not load things that are
not needed because of memory concerns. Perl has a standard way of
handling delayed loading, which is AUTOLOAD and the AutoLoader/autosplit
technique. The concern with that is that $r is currently an instance of
a class that is not always loaded, and that delayed loading defeats the
memory efficiency of preloading.
Here is what I suggest:
- Make $r an instance of a new class, something like
Apache::RequestHandle, or else keep it in RequestRec but always load
RequestRec.
- Define an AUTOLOAD method in that class which can load other modules
on demand when people call methods on $r.
- Provide import groups that preload the AUTOLOADed functions, similar
to what Josh said but still allowing AUTOLOADing of anything not
preloaded. This would be almost identical to the CGI.pm pre-compile stuff.
This would allow full backwards compatibility with the current API too,
at least for everything called through $r.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Stas Bekman wrote:
>
>> it's not the same. this call is:
>>
>> Apache::RequestUtil::is_initial_req('Apache::RequestUtil', $r)
>
> Right. That's what it should be, in my opinion. The $r object is not
> an instance of Apache::RequestUtil, so why would we want to call this
> method on $r?
but Apache::RequestUtil::is_initial_req expect an object blessed into
Apache::RequestRec. So:
$r->is_initial_req();
is fine.
>> Heh, I guess we have lost the track of who wants what. I started this
>> thread exactly suggesting to eliminate this obscurity and not
>> advocating for it.
>
>
> I'm for removing the Apache:: stuff you talked about and also clearing
> up the confusion caused by having classes like Apache::RequestUtil
> apparently defining methods in Apache::RequestRec.
>
> This seems to be what Boris is complaining about too, i.e. why does he
> have to load a whole bunch of separate modules if all of them just add
> things to $r?
>
>> that's what I've just suggested (Josh's idea). Though it's better be
>> some other common name which will handle any groups and not
>> Apache::RequestRec, because you don't necessarily need
>> Apache::RequestRec at all.
>
>
> Huh? Isn't $r an instance of Apache::RequestRec? If not, what is it?
It is. But you are confusing the name of the class 'Apache::RequestRec' with a
module Apache/RequestRec.(pm|so). You can perfectly use $r w/o ever loading
the module Apache/RequestRec.(pm|so).
Here is an example:
package MyLog;
use Apache::Log;
use Apache::Const -compile => 'OK';
sub handler {
my $r = shift;
$r->log_error("whatever");
return Apache::OK;
}
> I'm not a big fan of using the import() hooks like that. For one thing,
> CGI.pm doesn't die if you try to use something that you didn't pre-compile.
>
>> to be efficient it needs to do: goto &$AUTOLOAD; after loading
>> Apache::RequestUtil, so it'll happen only once.
>
>
> It could do that. Actually, within the context of these other classes
> that add stuff to $r, why can't they be AUTOLOADed? It doesn't seem
> like it would require a UNIVERSAL::AUTOLOAD, since all the methods are
> being called on one class.
Where would you install AUTOLOAD? In which class? Any class can be not loaded
when you are looking for another method in yet another not yet loaded class.
>> What if you don't load 'Apache::RequestRec'? Who is going to load that
>> wrapper?
>
> You're confusing me again. Is $r not an instance of Apache::RequestRec?
see above.
>> What if people do load Apache::RequestUtil:
>>
>> $r->is_initial_req($self)
>>
>> now you've sub redefined in either of the two modules.
>
>
> I'm not following. What is $self in this example?
sorry, copy-n-paste from your wrapper. Should be:
$r->is_initial_req()
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> it's not the same. this call is:
>
> Apache::RequestUtil::is_initial_req('Apache::RequestUtil', $r)
Right. That's what it should be, in my opinion. The $r object is not
an instance of Apache::RequestUtil, so why would we want to call this
method on $r?
> Heh, I guess we have lost the track of who wants what. I started this
> thread exactly suggesting to eliminate this obscurity and not advocating
> for it.
I'm for removing the Apache:: stuff you talked about and also clearing
up the confusion caused by having classes like Apache::RequestUtil
apparently defining methods in Apache::RequestRec.
This seems to be what Boris is complaining about too, i.e. why does he
have to load a whole bunch of separate modules if all of them just add
things to $r?
> that's what I've just suggested (Josh's idea). Though it's better be
> some other common name which will handle any groups and not
> Apache::RequestRec, because you don't necessarily need
> Apache::RequestRec at all.
Huh? Isn't $r an instance of Apache::RequestRec? If not, what is it?
I'm not a big fan of using the import() hooks like that. For one thing,
CGI.pm doesn't die if you try to use something that you didn't pre-compile.
> to be efficient it needs to do: goto &$AUTOLOAD; after loading
> Apache::RequestUtil, so it'll happen only once.
It could do that. Actually, within the context of these other classes
that add stuff to $r, why can't they be AUTOLOADed? It doesn't seem
like it would require a UNIVERSAL::AUTOLOAD, since all the methods are
being called on one class.
> What if you don't load 'Apache::RequestRec'? Who is going to load that
> wrapper?
You're confusing me again. Is $r not an instance of Apache::RequestRec?
> What if people do load Apache::RequestUtil:
>
> $r->is_initial_req($self)
>
> now you've sub redefined in either of the two modules.
I'm not following. What is $self in this example?
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Stas Bekman wrote:
>
>> Perrin Harkins wrote:
>>
>>> Geoffrey Young wrote:
>>>
>>>> it's definition is elsewhere, in
>>>> Apache::RequestUtil, but Apache::RequestUtil defines
>>>> Apache::RequestRec::is_initial_req(). the end result is that you
>>>> can have
>>>> the Perlish $r->is_initial_req() instead of the bulky
>>>> Apache::RequestUtil::is_initial_req($r).
>>>
>>>
>>>
>>>
>>> I would much prefer the longer one. It's more typing, but it also is
>>> much clearer. The current behavior just looks wrong to me.
>>
>>
>>
>> But Apache::RequestUtil::is_initial_req($r) is wrong. Because it a
>> method and not a function. It makes it impossible to subclass it.
>
>
> I was just following what Geoff said. The example still works if you
> make it Apache::RequestUtil->is_initial_req($r) instead.
it's not the same. this call is:
Apache::RequestUtil::is_initial_req('Apache::RequestUtil', $r)
>> That's just silly. Most people will need to load:
>> Apache::Request(Rec|IO|Util) and may be Apache::Server(Util)? I see no
>> legitimate reason to make things obscure.
>
>
> I'm not sure what you mean. Don't you think it's more obscure to
> require people to load class Foo in order to make a method in class Bar
> available? If they already have to explicitly load those modules, I
> can't see why calling methods in those modules would be more confusing.
Heh, I guess we have lost the track of who wants what. I started this thread
exactly suggesting to eliminate this obscurity and not advocating for it.
> Alternatively, you could provide arguments to import which would load
> support modules behind the scenes:
>
> use Apache::RequestRec qw(:io :util);
>
> I'm not crazy about that idea though, since it's a confusing use of import.
that's what I've just suggested (Josh's idea). Though it's better be some
other common name which will handle any groups and not Apache::RequestRec,
because you don't necessarily need Apache::RequestRec at all.
>>> Alternatively, you could be sneaky about it and load on demand,
>>> hiding this class completely from end users. Here's a simple exampe
>>> with no AUTOLOAD evil:
>>>
>>> sub is_initial_req {
>>> my $self = shift;
>>> require Apache::RequestUtil;
>>> return Apache::RequestUtil::is_initial_req($self);
>>> }
>>
>>
>>
>> yuck, that's so inefficient.
>
>
> It adds a hash lookup and one method call, and it would only exist for
> people who want to be able to say $r->is_initial_req(). People who are
> worried about efficiency would call
> Apache::RequestRecUtil->is_initial_req($r) instead.
to be efficient it needs to do: goto &$AUTOLOAD; after loading
Apache::RequestUtil, so it'll happen only once.
What if you don't load 'Apache::RequestRec'? Who is going to load that wrapper?
What if people do load Apache::RequestUtil:
$r->is_initial_req($self)
now you've sub redefined in either of the two modules.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> Perrin Harkins wrote:
>
>> Geoffrey Young wrote:
>>
>>> it's definition is elsewhere, in
>>> Apache::RequestUtil, but Apache::RequestUtil defines
>>> Apache::RequestRec::is_initial_req(). the end result is that you can
>>> have
>>> the Perlish $r->is_initial_req() instead of the bulky
>>> Apache::RequestUtil::is_initial_req($r).
>>
>>
>>
>> I would much prefer the longer one. It's more typing, but it also is
>> much clearer. The current behavior just looks wrong to me.
>
>
> But Apache::RequestUtil::is_initial_req($r) is wrong. Because it a
> method and not a function. It makes it impossible to subclass it.
I was just following what Geoff said. The example still works if you
make it Apache::RequestUtil->is_initial_req($r) instead.
> That's just silly. Most people will need to load:
> Apache::Request(Rec|IO|Util) and may be Apache::Server(Util)? I see no
> legitimate reason to make things obscure.
I'm not sure what you mean. Don't you think it's more obscure to
require people to load class Foo in order to make a method in class Bar
available? If they already have to explicitly load those modules, I
can't see why calling methods in those modules would be more confusing.
Alternatively, you could provide arguments to import which would load
support modules behind the scenes:
use Apache::RequestRec qw(:io :util);
I'm not crazy about that idea though, since it's a confusing use of import.
>> Alternatively, you could be sneaky about it and load on demand, hiding
>> this class completely from end users. Here's a simple exampe with no
>> AUTOLOAD evil:
>>
>> sub is_initial_req {
>> my $self = shift;
>> require Apache::RequestUtil;
>> return Apache::RequestUtil::is_initial_req($self);
>> }
>
>
> yuck, that's so inefficient.
It adds a hash lookup and one method call, and it would only exist for
people who want to be able to say $r->is_initial_req(). People who are
worried about efficiency would call
Apache::RequestRecUtil->is_initial_req($r) instead.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Geoffrey Young wrote:
>
>> it's definition is elsewhere, in
>> Apache::RequestUtil, but Apache::RequestUtil defines
>> Apache::RequestRec::is_initial_req(). the end result is that you can
>> have
>> the Perlish $r->is_initial_req() instead of the bulky
>> Apache::RequestUtil::is_initial_req($r).
>
>
> I would much prefer the longer one. It's more typing, but it also is
> much clearer. The current behavior just looks wrong to me.
But Apache::RequestUtil::is_initial_req($r) is wrong. Because it a method and
not a function. It makes it impossible to subclass it.
That's just silly. Most people will need to load: Apache::Request(Rec|IO|Util)
and may be Apache::Server(Util)? I see no legitimate reason to make things
obscure.
> Alternatively, you could be sneaky about it and load on demand, hiding
> this class completely from end users. Here's a simple exampe with no
> AUTOLOAD evil:
>
> sub is_initial_req {
> my $self = shift;
> require Apache::RequestUtil;
> return Apache::RequestUtil::is_initial_req($self);
> }
yuck, that's so inefficient.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
> it's definition is elsewhere, in
> Apache::RequestUtil, but Apache::RequestUtil defines
> Apache::RequestRec::is_initial_req(). the end result is that you can have
> the Perlish $r->is_initial_req() instead of the bulky
> Apache::RequestUtil::is_initial_req($r).
I would much prefer the longer one. It's more typing, but it also is
much clearer. The current behavior just looks wrong to me.
Alternatively, you could be sneaky about it and load on demand, hiding
this class completely from end users. Here's a simple exampe with no
AUTOLOAD evil:
sub is_initial_req {
my $self = shift;
require Apache::RequestUtil;
return Apache::RequestUtil::is_initial_req($self);
}
People who want to call the sub (shouldn't it actually be a method?)
directly for speed still can.
> why not just define is_initial_req() in Apache::RequestRec? well, for one
> it makes for a cleaner design: each of request_rec, server_rec,
> connection_rec have their own classes that provide access only to the slots
> in their specific record. but another good thing is that if your
> application only needs access to notes() and other request_rec attributes,
> then your code profile isn't bloated with symbols for is_initial_req() and
> other non-request_rec methods.
I think my approach above handles both of those. People who want to
preload can look at what's in %INC after running their app.
> while this may feel new, it's actually not: in mp1 you couldn't call
> $r->log->info without first loading Apache::Log, nor could you call
> $r->meets_conditions without first loading Apache::File.
But I didn't care then because those were obscure functions that I never
used...
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> For the record, I agree with Boris on this. Users should never be
> required to use methods defined in namespaces of modules that they did
> not explicitly load, and modules should not define things in other
> namespaces (like the Apache:: stuff that started this thread).
well, there are a few reasons for all of this. granted, it doesn't really
make sense before you, well, understand it, but I like it :) so, here's my
view on the whole thing...
take Apache::RequestRec. it implements methods that provde access to the
apache request_rec structure. so, load it and you get access to things like
$r->uri() and $r->notes(), which are stored as the uri and notes slots in
the C request_rec.
now, take a method like is_initial_req(), which represents access to
ap_is_initial_req. the call only makes sense at request-time, and the
Apache API requires a request_rec structure. but it doesn't make sense to
define it in Apache::RequestRec, since it does not access a property of the
request_rec structure. so, it's definition is elsewhere, in
Apache::RequestUtil, but Apache::RequestUtil defines
Apache::RequestRec::is_initial_req(). the end result is that you can have
the Perlish $r->is_initial_req() instead of the bulky
Apache::RequestUtil::is_initial_req($r). basically, in Perl we get an API
that makes sense: operations that require a request_rec in C are called from
$r in Perl.
why not just define is_initial_req() in Apache::RequestRec? well, for one
it makes for a cleaner design: each of request_rec, server_rec,
connection_rec have their own classes that provide access only to the slots
in their specific record. but another good thing is that if your
application only needs access to notes() and other request_rec attributes,
then your code profile isn't bloated with symbols for is_initial_req() and
other non-request_rec methods.
while this may feel new, it's actually not: in mp1 you couldn't call
$r->log->info without first loading Apache::Log, nor could you call
$r->meets_conditions without first loading Apache::File. I suspect (but
don't know for certain) that this was an implementation style that popped up
later in mp1's lifecycle, and that Doug decided it was the way mp2 ought to
work.
personally, I'm really in favor of the way things look now (save the things
that started this thread). not only do they represent a cleaner Perl API
layer (my favorite part) but they allow applications to keep unnecessary
symbols out of their code. granted, it takes a while to get used to, but I
like it and I hope it will grow on everyone as it has on me.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Perrin Harkins <pe...@elem.com>.
Boris Zentner wrote:
> RequestIO is not inhereted from RequestRec. Also I have not created a object
> of type RequestIO they are just unrelated to eachother. I whould expect a
> full working object from the beginning. If my program does more than passing
> a obj ref around the I know I have to load this object's module. use
> Apache::RequestRec nothing more.
>
> This is the same for all other Apache::* modules, please do not populate
> others namespace without reason. Nor bother a user to load a module he did
> not use.
For the record, I agree with Boris on this. Users should never be
required to use methods defined in namespaces of modules that they did
not explicitly load, and modules should not define things in other
namespaces (like the Apache:: stuff that started this thread).
I don't have any production mp2 code, so I'm probably less worried about
backwards compatibility than some people, but I think you could handle
the issue with some alias methods that print a warning about being
deprecated and then call the new method names.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman:
> Please take a look at this new manpage
> http://perl.apache.org/docs/2.0/api/Apache.html
>
> This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was OK
> to have functions like Apache::current_callback() because almost everything
> was preloaded. I don't think it's OK in mp2. It's absolutely not obvious
> which module needs to be loaded to get this API, and most people will try
> to load Apache, and it won't do the trick.
>
This is very confusing and incomprehencible to me. My last mp2 application
starts with:
use mod_perl 1.99;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::ServerUtil ();
use Apache::RequestUtil ();
use Apache::Util ();
use APR::Date ();
use APR::Table();
and im sure my next project start with this lines too. If someone ask why my
answer is I do not know, but it does not work otherwise.
perldoc does not know anything of the above.
On startup, my handler get a RequestRec object, but to use parts of it I have
to load another module 'Apache::RequestIO'. This powers my requestrec up, but
why and how???
RequestIO is not inhereted from RequestRec. Also I have not created a object
of type RequestIO they are just unrelated to eachother. I whould expect a
full working object from the beginning. If my program does more than passing
a obj ref around the I know I have to load this object's module. use
Apache::RequestRec nothing more.
This is the same for all other Apache::* modules, please do not populate
others namespace without reason. Nor bother a user to load a module he did
not use.
> Why not replace:
>
> use ModPerl::Util;
> my $callback = Apache::current_callback();
>
> with:
>
> use ModPerl::Util;
> my $callback = ModPerl::Util::current_callback();
please do so ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> then:
>
> use Apache::ServerUtil;
> my $server_root = Apache::server_root;
>
> with:
>
> use Apache::ServerUtil;
> my $server_root = Apache::ServerUtil::server_root;
this is what I whould expect.
>
> etc. (there are many modules which install things into the Apache::
> namespace). i.e. try to use the same namespace as the module the function
> lives in.
>
> The only obvious need-to-keep is Apache->server, which can really be made a
> constant too.
>
> or do you think it's OK the way things are right now? The manpage suggests
no, please not.
> to use http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html to
> figure what needs to be loaded, but it's not so intuitive.
>
> The only real problem with this change suggestion is backwards
> compatibility, which is nice to keep small.
I think backwards compatibility is not of interest here, mod_perl2 is not
released and nearly everything has a new name rightnow. The number of users
that have really production mp2 applications is small and the one that runs a
old source with Apache::compat can do so, he did not notice the changes
anyway.
>
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: cleaning up Apache:: namespace
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> I just couldn't keep up with the multiple threads under the old subject :)
but also what would have helped is not to reply to the same message, but start
a new one and copy the reply to it. You've changed the subject but mail
clients still file them under the original thread, because of the:
References: <40...@stason.org> <40...@modperlcookbook.org>
<40...@stason.org> <p05111b02bc2d5348ab0b@[192.168.56.3]>
<40...@stason.org> <p05111b06bc2d5b097c63@[192.168.56.3]>
<40...@stason.org> <p05111b07bc2d5dce2295@[192.168.56.3]>
<40...@stason.org> <40...@modperlcookbook.org>
<40...@stason.org>
>>>my reading of method_register() is that it's global to all requests - it
>>>doesn't make sense to define a new http method during a request. so,
>>>move
>>>that to Apache::Server::method_register() (defined in ServerUtil)
>>
>>
>>It actually does, see the example at:
>>http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler
>>
>>though I see no reason why not to have Apache::Server::method_register()
>>
>>+1
>
>
> using it that way means that you attempt to register the EMAIL method for
> the entire server for every call to that uri, even though its scope is for
> the lifetime of the server - it doesn't un-register at the end of a request.
>
> so, I'd suggest changing that example a bit. mod_dav calls
> ap_method_register during post_config, so maybe that's a better place for
> it. beware of which pool you use as well.
Good point, Geoff. I'll fix the example.
>>>current_callback() is a tough one. maybe we could do it similar to
>>>server_root_relative: support only object methods but both
>>>$s->current_callback and $r->current_callback, since it's phase related.
>>
>>
>>why? if it can work transparently to where it is called from, why
>>complicating it with requiring an object? I think it's just fine with
>>how it is. Just move it to Apache::Server::current_callback. Actually I
>>thought that it really belongs to ModPerl::Util::current_callback since
>>it gives us mp callbacks, not the apache ones.
>
>
> hmm, ok, maybe you're right. but I think I prefer
> Apache::Server::current_callback() - if we used ModPerl::Util it would make
> it the only API in the ModPerl namespace (I think) which is kinda strange.
Why? We will surely add more in the future. But for example calling
Apache::Server::current_callback() at the server startup sounds wrong. Since
there is no server at that point.
>>>that leaves Apache::request and Apache::server. I may have changed my
>>>mind
>>>about these, thinking it best to keep them where they are. But
>>>Apache::RequestRec->new() and Apache::Server->new() also have a certain
>>>appeal, so long as everyone understand the singleton-esque nature of the
>>>constructors.
>>
>>
>>I'm not sure what new() has to do with it. But I'm certainly fine with
>>Apache::RequestRec->request and Apache::Server->server I'd even add the
>>current_ into the API. Do you think they need to be class methods and
>>not just functions?
>
>
> I need to think a bit on these. for one, there's already an
> Apache::RequestRec->new and I need to see what it does.
I think that one is handy for the yet-to-be-written FakeRequest based on APR.
Or may be not, that FakeRequest shouldn't depend on modperl.so. I'm not sure then.
> at any rate, that's enough for one day :)
>
>
>>This change will require special "ifdef" on the modperl version in
>>certain CPAN modules, like CGI.pm :( So it's not only about those brave
>>bleeding edge users, but CPAN authors hell.
>
> well, I don't think it's hell. a bit of a pain, yes...
;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
cleaning up Apache:: namespace
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
I just couldn't keep up with the multiple threads under the old subject :)
>> my reading of method_register() is that it's global to all requests - it
>> doesn't make sense to define a new http method during a request. so,
>> move
>> that to Apache::Server::method_register() (defined in ServerUtil)
>
>
> It actually does, see the example at:
> http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler
>
> though I see no reason why not to have Apache::Server::method_register()
>
> +1
using it that way means that you attempt to register the EMAIL method for
the entire server for every call to that uri, even though its scope is for
the lifetime of the server - it doesn't un-register at the end of a request.
so, I'd suggest changing that example a bit. mod_dav calls
ap_method_register during post_config, so maybe that's a better place for
it. beware of which pool you use as well.
>> current_callback() is a tough one. maybe we could do it similar to
>> server_root_relative: support only object methods but both
>> $s->current_callback and $r->current_callback, since it's phase related.
>
>
> why? if it can work transparently to where it is called from, why
> complicating it with requiring an object? I think it's just fine with
> how it is. Just move it to Apache::Server::current_callback. Actually I
> thought that it really belongs to ModPerl::Util::current_callback since
> it gives us mp callbacks, not the apache ones.
hmm, ok, maybe you're right. but I think I prefer
Apache::Server::current_callback() - if we used ModPerl::Util it would make
it the only API in the ModPerl namespace (I think) which is kinda strange.
>
>> that leaves Apache::request and Apache::server. I may have changed my
>> mind
>> about these, thinking it best to keep them where they are. But
>> Apache::RequestRec->new() and Apache::Server->new() also have a certain
>> appeal, so long as everyone understand the singleton-esque nature of the
>> constructors.
>
>
> I'm not sure what new() has to do with it. But I'm certainly fine with
> Apache::RequestRec->request and Apache::Server->server I'd even add the
> current_ into the API. Do you think they need to be class methods and
> not just functions?
I need to think a bit on these. for one, there's already an
Apache::RequestRec->new and I need to see what it does.
at any rate, that's enough for one day :)
>
> This change will require special "ifdef" on the modperl version in
> certain CPAN modules, like CGI.pm :( So it's not only about those brave
> bleeding edge users, but CPAN authors hell.
well, I don't think it's hell. a bit of a pain, yes...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>e.g. Apache::document_root living in Apache
>>vs Apache::ServerUtil::document_root living where it is now
>>(Apache::ServerUtil)
>
>
> actually, it lives in RequestUtil, though it probably should be in ServerUtil.
>
> I grep'd through the code and here are the Apache:: functions I find
[...]
> for the unescape_url(), LOG_MARK(), and log_pid(), I see no reason why they
> can't live in the classes that define them (that is, changing it to
> Apache::URI::unescape_url)
+1
> my reading of method_register() is that it's global to all requests - it
> doesn't make sense to define a new http method during a request. so, move
> that to Apache::Server::method_register() (defined in ServerUtil)
It actually does, see the example at:
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler
though I see no reason why not to have Apache::Server::method_register()
+1
> add_version_component(), exists_config_define(), get_server_built(),
> get_status_line(), and get_server_version() are all built-in server
> properties, so put them in Apache::Server as well (defined in ServerUtil).
+1
> server_root_relative() belongs in ServerUtil, so
> Apache::Server::server_root_relative() here too.
+1
> current_callback() is a tough one. maybe we could do it similar to
> server_root_relative: support only object methods but both
> $s->current_callback and $r->current_callback, since it's phase related.
why? if it can work transparently to where it is called from, why complicating
it with requiring an object? I think it's just fine with how it is. Just move
it to Apache::Server::current_callback. Actually I thought that it really
belongs to ModPerl::Util::current_callback since it gives us mp callbacks, not
the apache ones.
> that leaves Apache::request and Apache::server. I may have changed my mind
> about these, thinking it best to keep them where they are. But
> Apache::RequestRec->new() and Apache::Server->new() also have a certain
> appeal, so long as everyone understand the singleton-esque nature of the
> constructors.
I'm not sure what new() has to do with it. But I'm certainly fine with
Apache::RequestRec->request and Apache::Server->server I'd even add the
current_ into the API. Do you think they need to be class methods and not just
functions?
This change will require special "ifdef" on the modperl version in certain
CPAN modules, like CGI.pm :( So it's not only about those brave bleeding edge
users, but CPAN authors hell.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
[...]
>>In which case it seems that you are saying exactly what Liz does: i.e. you
>>want to be able to load only the modules that you are going to use. Nobody
>>is forcing you to use AUTOLOAD if you don't want to. Or may be I've lost
>>you and not quite following what your point/disagreement is.
>
>
> This is what happened so far ( or what I read so far ):
> Liz: suggested if a method is not found we can use autoload to load with a
> warning. That is better as error. AND this aproach is a good one, if you use
> a ithread using server.
>
> Boris: Yes this is nice, but if someone use a forked server it whould be far
> better not to load all this functions on demand because it use so much more
> mem. I agree with liz. But for my kind of server this is not the all time
> best, it is better as before ;-)
It's clear now, Boris. I thought you were arguing for preloading all modules
before. Don't worry, we won't use AUTOLOAD, since as I've explained it doesn't
quite work everywhere (because it's not AUTOLOAD but UNIVERSAL::AUTOLOAD).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Am Sonntag, 18. Januar 2004 06:35 schrieb Stas Bekman:
> Boris Zentner wrote:
> > Hi,
> >
> > Am Sonntag, 18. Januar 2004 01:13 schrieb Stas Bekman:
> >>Boris Zentner wrote:
> >>>>Anyway, loading these methods on demand may actually be very useful
> >>>>for Perl 5 ithreaded based MPM's!
> >>>
> >>>but for forkbased servers it is just the opposite. I dislike your
> >>>AUTOLOAD idea for that reason.
> >>
> >>It's not quite opposite. You don't want to load 40+ modules if you are
> >>going to use only 3 of them. It's out of question that we are going to
> >>preload them by default. You are probably unaware that there are that
> >> many modules in mp2.
> >
> > I do not want to preload all modules, I like to preload my modules, and
> > only the ones I need before apache forks. Just to share them at least at
> > this point.
> >
> > With the autoload aproach all my server load the missing functions after
> > each other and need x times more mem.
> >
> > Sorry if this was not so clear.
>
> In which case it seems that you are saying exactly what Liz does: i.e. you
> want to be able to load only the modules that you are going to use. Nobody
> is forcing you to use AUTOLOAD if you don't want to. Or may be I've lost
> you and not quite following what your point/disagreement is.
This is what happened so far ( or what I read so far ):
Liz: suggested if a method is not found we can use autoload to load with a
warning. That is better as error. AND this aproach is a good one, if you use
a ithread using server.
Boris: Yes this is nice, but if someone use a forked server it whould be far
better not to load all this functions on demand because it use so much more
mem. I agree with liz. But for my kind of server this is not the all time
best, it is better as before ;-)
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
> Hi,
>
> Am Sonntag, 18. Januar 2004 01:13 schrieb Stas Bekman:
>
>>Boris Zentner wrote:
>>
>>>>Anyway, loading these methods on demand may actually be very useful
>>>>for Perl 5 ithreaded based MPM's!
>>>
>>>but for forkbased servers it is just the opposite. I dislike your
>>>AUTOLOAD idea for that reason.
>>
>>It's not quite opposite. You don't want to load 40+ modules if you are
>>going to use only 3 of them. It's out of question that we are going to
>>preload them by default. You are probably unaware that there are that many
>>modules in mp2.
>>
>
>
> I do not want to preload all modules, I like to preload my modules, and only
> the ones I need before apache forks. Just to share them at least at this
> point.
>
> With the autoload aproach all my server load the missing functions after each
> other and need x times more mem.
>
> Sorry if this was not so clear.
In which case it seems that you are saying exactly what Liz does: i.e. you
want to be able to load only the modules that you are going to use. Nobody is
forcing you to use AUTOLOAD if you don't want to. Or may be I've lost you and
not quite following what your point/disagreement is.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Sonntag, 18. Januar 2004 01:13 schrieb Stas Bekman:
> Boris Zentner wrote:
> >>Anyway, loading these methods on demand may actually be very useful
> >>for Perl 5 ithreaded based MPM's!
> >
> > but for forkbased servers it is just the opposite. I dislike your
> > AUTOLOAD idea for that reason.
>
> It's not quite opposite. You don't want to load 40+ modules if you are
> going to use only 3 of them. It's out of question that we are going to
> preload them by default. You are probably unaware that there are that many
> modules in mp2.
>
I do not want to preload all modules, I like to preload my modules, and only
the ones I need before apache forks. Just to share them at least at this
point.
With the autoload aproach all my server load the missing functions after each
other and need x times more mem.
Sorry if this was not so clear.
> If you really want to there is
> ModPerl::MethodLookup::preload_all_modules(), but please keep it in your
> config and don't put it in any CPAN modules:
> http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_preload_all
>_modules___
>
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Boris Zentner wrote:
>>Anyway, loading these methods on demand may actually be very useful
>>for Perl 5 ithreaded based MPM's!
>>
>
>
> but for forkbased servers it is just the opposite. I dislike your AUTOLOAD
> idea for that reason.
It's not quite opposite. You don't want to load 40+ modules if you are going
to use only 3 of them. It's out of question that we are going to preload them
by default. You are probably unaware that there are that many modules in mp2.
If you really want to there is ModPerl::MethodLookup::preload_all_modules(),
but please keep it in your config and don't put it in any CPAN modules:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_preload_all_modules___
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 18:02 +0100 1/17/04, Boris Zentner wrote:
>Am Samstag, 17. Januar 2004 16:16 schrieb Elizabeth Mattijsen:
>[...]
>> Anyway, loading these methods on demand may actually be very useful
> > for Perl 5 ithreaded based MPM's!
>but for forkbased servers it is just the opposite. I dislike your AUTOLOAD
>idea for that reason.
Exactly for that reason I once developed the "load.pm" module on
CPAN. In prefork MPM's it would automatically load all of the subs,
in other environmens it would load on demand.
Maybe something similar could be done here?
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Boris Zentner <bz...@2bz.de>.
Hi,
Am Samstag, 17. Januar 2004 16:16 schrieb Elizabeth Mattijsen:
[...]
> Anyway, loading these methods on demand may actually be very useful
> for Perl 5 ithreaded based MPM's!
>
but for forkbased servers it is just the opposite. I dislike your AUTOLOAD
idea for that reason.
>
> Liz
--
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> > the right module and just makes the right sub gets called?
>> IIRC MethodLookup does have a 'load all' feature. but other than
>> that, see
>> Apache::porting.
>
>
> That's fine, but that's introducing bloat (which may not be such a
> problem with perfork MPM's, but _may_ be a problem with other MPM's,
> particularly based on Perl 5 ithreads).
of course. they are just meant to get you past the porting hurdle.
>
> Maybe it shouldn't be an AUTOLOAD, but a custom die() handler... ;-)
Apache::porting is close to this I think. I haven't used it, but that's how
stas has described it.
>
> Anyway, loading these methods on demand may actually be very useful for
> Perl 5 ithreaded based MPM's!
:)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 01:07 -0800 1/18/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>> >Coming back to the original issue. Is it really so bad to load
>> everything "automatically" if >you're using a prefork MPM?
>> You can if you want to. That's definitely won't be the default. Don't
>> forget that mp2 is much more than mp1. And people may want to use just
>> one of its modules (e.g. a filter) w/o using modperl itself. Would you
>> want to have 40+ modules preloaded for you when you need only 2?
>
>
> Well, yes. But that is tuning. If you want people to easily migrate, I
> think making it the default would be best from a user friendliness point
> of view. Maybe add a warning to the error log if you're doing it the
> lazy way.
>
> *** Note: currently all xxxx modules have been loaded. This may not
> be the most efficient
> *** way of using Apache 2. Please check xxxx for more tuning
> information.
>
> Ideally, have a message added to the error log at shutdown time with a
> list of modules that
> were actually used during the run,
>
> *** According to usage statistics, you should change the following
> lines in your config:
> aaaa
> bbbb
> ccccc
>
> although I wonder how one would do that.
Many people don't look in their error_log files.
Many people find it annoying when they error_log files contain messages they
haven't asked for.
For an easy transition load Apache::compat. It already loads all the modules
for APIs you've used in mp1.
If you want to preload all add ModPerl::MethodLookup::preload_all_modules to
startup.pl. This can't be the default behavior.
> Just brainstorming here: maybe the default should be to load just
> package specific AUTOLOAD subs for each package, whose only function
> would be to set a flag that the package was being used and then load the
> real package?
>
> Something like (more or less pseudo code here)
>
> startup:
>
> foreach (qw(Foo Bar)) { # all of the appropriate Apache modules
> my $package = "Apache::$_";
> *{$package.'::AUTOLOAD'} = sub {
> if ($INC{$package}) {
> # real error, sub not found after package loaded
> } else {
> (my $filename = $package) =~ s#::#/#s;
> require "$filename.pm";
> goto &${$package.'::AUTOLOAD'};
> }
> }
> }
>
>
> shutdown:
>
> my @module;
> foreach (qw(Foo Bar)) {
> my $package = "Apache::$_";
> push @module,$INC{$package};
> }
> if (@module) {
> warn "*** According to....\n";
> warn " $_\n" foreach @module;
> }
It's totally up to you. Feel free to release a CPAN module which does any of
these tricks and people can easier re-use it if they want to. This is really
beyong the core support and will confuse people more than it'll help them.
I'm off to sleep ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 01:07 -0800 1/18/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
> >Coming back to the original issue. Is it really so bad to load
>everything "automatically" if >you're using a prefork MPM?
>You can if you want to. That's definitely won't be the default.
>Don't forget that mp2 is much more than mp1. And people may want to
>use just one of its modules (e.g. a filter) w/o using modperl
>itself. Would you want to have 40+ modules preloaded for you when
>you need only 2?
Well, yes. But that is tuning. If you want people to easily
migrate, I think making it the default would be best from a user
friendliness point of view. Maybe add a warning to the error log if
you're doing it the lazy way.
*** Note: currently all xxxx modules have been loaded. This may
not be the most efficient
*** way of using Apache 2. Please check xxxx for more tuning information.
Ideally, have a message added to the error log at shutdown time with
a list of modules that
were actually used during the run,
*** According to usage statistics, you should change the following
lines in your config:
aaaa
bbbb
ccccc
although I wonder how one would do that.
Just brainstorming here: maybe the default should be to load just
package specific AUTOLOAD subs for each package, whose only function
would be to set a flag that the package was being used and then load
the real package?
Something like (more or less pseudo code here)
startup:
foreach (qw(Foo Bar)) { # all of the appropriate Apache modules
my $package = "Apache::$_";
*{$package.'::AUTOLOAD'} = sub {
if ($INC{$package}) {
# real error, sub not found after package loaded
} else {
(my $filename = $package) =~ s#::#/#s;
require "$filename.pm";
goto &${$package.'::AUTOLOAD'};
}
}
}
shutdown:
my @module;
foreach (qw(Foo Bar)) {
my $package = "Apache::$_";
push @module,$INC{$package};
}
if (@module) {
warn "*** According to....\n";
warn " $_\n" foreach @module;
}
> > It will all get shared, won't it?
>You know how well perl gets its sharing working. Even though most of
>this code is C, it manipulates perl vars internally so a lot of it
>won't survive sharing.
True.
>>Or is the problem that you don't know which MPM you're using when
>>the first PerlRequire is being handled?
>No, whe should know which mpm is used once mp is loaded and before
>any of its modules are loaded (well we need to load Apache::MPM for
>that purpose if we want to know that in perl)
Good. So that shouldn't be the problem then...
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
[...]
> Coming back to the original issue. Is it really so bad to load
> everything "automatically" if you're using a prefork MPM?
You can if you want to. That's definitely won't be the default. Don't forget
that mp2 is much more than mp1. And people may want to use just one of its
modules (e.g. a filter) w/o using modperl itself. Would you want to have 40+
modules preloaded for you when you need only 2?
> It will all get shared, won't it?
You know how well perl gets its sharing working. Even though most of this code
is C, it manipulates perl vars internally so a lot of it won't survive sharing.
> Or is the problem that you don't know which MPM
> you're using when the first PerlRequire is being handled?
No, whe should know which mpm is used once mp is loaded and before any of its
modules are loaded (well we need to load Apache::MPM for that purpose if we
want to know that in perl)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
Argh,
I should first wake up before coming up with any suggestions...
At 09:05 +0100 1/18/04, Elizabeth Mattijsen wrote:
>I was more thinking along the lines:
>
> BEGIN { *CORE::GLOBAL::die = sub {
> warn "We're not dieing with @_\n";
> } };
> die "This is it!";
> warn "Well, I guess it wasn't.\n";
BEGIN { *CORE::GLOBAL::die = sub {
warn "We're not dieing with @_\n";
} };
doesntexist( 'Hello world' );
shows that even though die() was stolen, it's not internally called
by Perl. ;-(
Coming back to the original issue. Is it really so bad to load
everything "automatically" if you're using a prefork MPM? It will
all get shared, won't it? Or is the problem that you don't know
which MPM you're using when the first PerlRequire is being handled?
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 16:19 -0800 1/17/04, Stas Bekman wrote:
>
>> And it's not on by default, because AUTOLOAD introduces all kind of
>> problems. And as explained in:
>> http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
>> and I weren't able to use it in any phase before PerlChildInitHandler,
>> which means that it won't work for your startup.pl.
>>
>> The problem comes from the fact that we need to use
>> UNIVERSAL::AUTOLOAD. We can't use plain package AUTOLOAD, precisely
>> because of the chicken and egg problem. We don't know which module to
>> load, and if we load them all, we don't need AUTOLOAD. So I figured
>> UNIVERSAL::AUTOLOAD is the only workable solution.
>>
>> If you have better ideas solving this problem I'm all ears.
>
>
>
> "Moreover installing UNIVERSAL::AUTOLOAD may cause a lot of problems,
> since once it's installed Perl will call it every time some method is
> missing (e.g. undefined DESTROY methods)."
>
> Well, the DESTROY method issue could be fixed with adding a:
>
> sub UNIVERSAL::DESTROY { undef }
>
> method? (note I'm adding an undef here because 5.8.2 has an issue with
> empty subs).
Have you tried that during the server startup phases? I don't remember now but
I was getting all sort of errors and segfaults when I was trying to use
UNIVERSAL::AUTOLOAD at the server startup.
>>> That's fine, but that's introducing bloat (which may not be such a
>>> problem with perfork MPM's, but _may_ be a problem with other MPM's,
>>> particularly based on Perl 5 ithreads).
>>> Maybe it shouldn't be an AUTOLOAD, but a custom die() handler... ;-)
>>
>> But someone needs to trigger that custom die() handler. Or are you
>> talking about installing $SIG{__DIE__} instead of using AUTOLOAD for
>> trapping? You are aware that doing that comes with its own pile of
>> problems, in certain contexts (.e.g. eval {} blocks)
>
>
> I was more thinking along the lines:
>
> BEGIN { *CORE::GLOBAL::die = sub {
> warn "We're not dieing with @_\n";
> } };
> die "This is it!";
> warn "Well, I guess it wasn't.\n";
Of course it needs to handle the case if someone has already redefined
CORE::GLOBAL::die. But certainly this is another option, which I haven't
tried. If you can test that it works and post a patch to the
ModPerl::MethodLookup manpage, that would be great. It should be very similar
to the AUTOLOAD example and perhaps we could provide an API to turn that
handler on w/o doing copy-n-paste.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 16:19 -0800 1/17/04, Stas Bekman wrote:
>And it's not on by default, because AUTOLOAD introduces all kind of
>problems. And as explained in:
>http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
>and I weren't able to use it in any phase before
>PerlChildInitHandler, which means that it won't work for your
>startup.pl.
>
>The problem comes from the fact that we need to use
>UNIVERSAL::AUTOLOAD. We can't use plain package AUTOLOAD, precisely
>because of the chicken and egg problem. We don't know which module
>to load, and if we load them all, we don't need AUTOLOAD. So I
>figured UNIVERSAL::AUTOLOAD is the only workable solution.
>
>If you have better ideas solving this problem I'm all ears.
"Moreover installing UNIVERSAL::AUTOLOAD may cause a lot of problems,
since once it's installed Perl will call it every time some method is
missing (e.g. undefined DESTROY methods)."
Well, the DESTROY method issue could be fixed with adding a:
sub UNIVERSAL::DESTROY { undef }
method? (note I'm adding an undef here because 5.8.2 has an issue
with empty subs).
>>That's fine, but that's introducing bloat (which may not be such a
>>problem with perfork MPM's, but _may_ be a problem with other
>>MPM's, particularly based on Perl 5 ithreads).
>>Maybe it shouldn't be an AUTOLOAD, but a custom die() handler... ;-)
>But someone needs to trigger that custom die() handler. Or are you
>talking about installing $SIG{__DIE__} instead of using AUTOLOAD for
>trapping? You are aware that doing that comes with its own pile of
>problems, in certain contexts (.e.g. eval {} blocks)
I was more thinking along the lines:
BEGIN { *CORE::GLOBAL::die = sub {
warn "We're not dieing with @_\n";
} };
die "This is it!";
warn "Well, I guess it wasn't.\n";
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 10:07 -0500 1/17/04, Geoffrey Young wrote:
>
>> > I realize (now) that there is a way to find out which method
>> > resides in which module:
>> http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded
>>
>> > but why does this have to be done manually? Why can't there be an
>>
>>> AUTOLOAD sub that _by default_ puts a warning in the error log, loads
>>
>> > the right module and just makes the right sub gets called?
>> IIRC MethodLookup does have a 'load all' feature. but other than
>> that, see
>> Apache::porting.
And it's not on by default, because AUTOLOAD introduces all kind of problems.
And as explained in:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
and I weren't able to use it in any phase before PerlChildInitHandler, which
means that it won't work for your startup.pl.
The problem comes from the fact that we need to use UNIVERSAL::AUTOLOAD. We
can't use plain package AUTOLOAD, precisely because of the chicken and egg
problem. We don't know which module to load, and if we load them all, we don't
need AUTOLOAD. So I figured UNIVERSAL::AUTOLOAD is the only workable solution.
If you have better ideas solving this problem I'm all ears.
> That's fine, but that's introducing bloat (which may not be such a
> problem with perfork MPM's, but _may_ be a problem with other MPM's,
> particularly based on Perl 5 ithreads).
>
> Maybe it shouldn't be an AUTOLOAD, but a custom die() handler... ;-)
But someone needs to trigger that custom die() handler. Or are you talking
about installing $SIG{__DIE__} instead of using AUTOLOAD for trapping? You are
aware that doing that comes with its own pile of problems, in certain contexts
(.e.g. eval {} blocks)
> Anyway, loading these methods on demand may actually be very useful for
> Perl 5 ithreaded based MPM's!
;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 10:07 -0500 1/17/04, Geoffrey Young wrote:
> > I realize (now) that there is a way to find out which method
> > resides in which module:
>http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded
> > but why does this have to be done manually? Why can't there be an
>> AUTOLOAD sub that _by default_ puts a warning in the error log, loads
> > the right module and just makes the right sub gets called?
>IIRC MethodLookup does have a 'load all' feature. but other than that, see
>Apache::porting.
That's fine, but that's introducing bloat (which may not be such a
problem with perfork MPM's, but _may_ be a problem with other MPM's,
particularly based on Perl 5 ithreads).
Maybe it shouldn't be an AUTOLOAD, but a custom die() handler... ;-)
Anyway, loading these methods on demand may actually be very useful
for Perl 5 ithreaded based MPM's!
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> What I really find annoying, is that when you're porting, things start
> to fail.
agreed. that's even the basis for the mp2 talk I've been giving and the
article I wrote for perl.com - porting is lots more frustrating than we
sometimes make it out to be.
> I realize (now) that there is a way to find out which method
> resides in which module:
>
> http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded
>
>
> but why does this have to be done manually? Why can't there be an
> AUTOLOAD sub that _by default_ puts a warning in the error log, loads
> the right module and just makes the right sub gets called?
IIRC MethodLookup does have a 'load all' feature. but other than that, see
Apache::porting.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 18:28 -0800 1/16/04, Stas Bekman wrote:
>Geoffrey Young wrote:
>>2) liz, your opinion here is especially valuable wrt what is "intuitive."
>>stas and I both have our own (generally differing) opinion of API
>>intuitiveness, and as someone who is in the middle of figuring out the new
>>API, you represent a good test case. of course, if we don't agree with your
>>opinion, well... ;)
>May be we should open up this question for more people?
Please do. I don't think I can qualify as a "user" in that respect.
Yes, I have used mod_perl from almost the very beginning, but there
has been a "hole" in my experience from say 1999 through 2002...
>There are quite a few folks who have moved to mp2 or in the process
>of doing so and certainly will have things to say. I'd suggest to
>ask for their input of what people have found hard and whether we
>need to change things before 2.0 is cast in stone.
>Certainly we aren't oblidged to follow all the suggestions, but it's
>a good idea to hear what users have to say.
What I really find annoying, is that when you're porting, things
start to fail. I realize (now) that there is a way to find out which
method resides in which module:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded
but why does this have to be done manually? Why can't there be an
AUTOLOAD sub that _by default_ puts a warning in the error log, loads
the right module and just makes the right sub gets called?
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> two things I forgot to mention in that last email...
>
> 1) of course, I volunteer to do all the munging, once everyone agrees on
> what the API ought to be
Thanks Geoff, but let's do the next thing first before changing those things
(see my next comment).
> 2) liz, your opinion here is especially valuable wrt what is "intuitive."
> stas and I both have our own (generally differing) opinion of API
> intuitiveness, and as someone who is in the middle of figuring out the new
> API, you represent a good test case. of course, if we don't agree with your
> opinion, well... ;)
May be we should open up this question for more people? There are quite a few
folks who have moved to mp2 or in the process of doing so and certainly will
have things to say. I'd suggest to ask for their input of what people have
found hard and whether we need to change things before 2.0 is cast in stone.
Certainly we aren't oblidged to follow all the suggestions, but it's a good
idea to hear what users have to say.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
two things I forgot to mention in that last email...
1) of course, I volunteer to do all the munging, once everyone agrees on
what the API ought to be
2) liz, your opinion here is especially valuable wrt what is "intuitive."
stas and I both have our own (generally differing) opinion of API
intuitiveness, and as someone who is in the middle of figuring out the new
API, you represent a good test case. of course, if we don't agree with your
opinion, well... ;)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> e.g. Apache::document_root living in Apache
> vs Apache::ServerUtil::document_root living where it is now
> (Apache::ServerUtil)
actually, it lives in RequestUtil, though it probably should be in ServerUtil.
I grep'd through the code and here are the Apache:: functions I find
from Apache::URI
Apache::unescape_url
from ModPerl::Util
Apache::current_callback
from Apache::Log
Apache::LOG_MARK
Apache::log_pid
from Apache::RequestUtil
Apache::request
Apache::method_register
Apache::get_status_line
from Apache::ServerUtil
Apache::add_version_component
Apache::exists_config_define
Apache::get_server_built
Apache::get_server_version
Apache::server
Apache::server_root_relative
for the unescape_url(), LOG_MARK(), and log_pid(), I see no reason why they
can't live in the classes that define them (that is, changing it to
Apache::URI::unescape_url)
my reading of method_register() is that it's global to all requests - it
doesn't make sense to define a new http method during a request. so, move
that to Apache::Server::method_register() (defined in ServerUtil)
add_version_component(), exists_config_define(), get_server_built(),
get_status_line(), and get_server_version() are all built-in server
properties, so put them in Apache::Server as well (defined in ServerUtil).
server_root_relative() belongs in ServerUtil, so
Apache::Server::server_root_relative() here too.
current_callback() is a tough one. maybe we could do it similar to
server_root_relative: support only object methods but both
$s->current_callback and $r->current_callback, since it's phase related.
that leaves Apache::request and Apache::server. I may have changed my mind
about these, thinking it best to keep them where they are. But
Apache::RequestRec->new() and Apache::Server->new() also have a certain
appeal, so long as everyone understand the singleton-esque nature of the
constructors.
HTH
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 01:15 -0800 1/16/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> At 01:05 -0800 1/16/04, Stas Bekman wrote:
>>>
>>>> This is changing, take a look at: http://perl.apache.org/docs/2.0/api/
>>>
>>> Still far from complete, last time I looked.
>>
>> Please look again. Most API is in place (though only skeletons which
>> need further review and expansion).
>
>
> Still far from complete ;-) Skeletons are nice to work with, but
> don't tell you anything as a user.
Baby steps ;)
>>>> >The current setup (in the final stages of getting this going for a
>>>> client right now) is _very_ >confusing.
>>>> What do you mean? The thing I'm talking about?
>>>
>>> Yep.
>>
>> So what would you suggest to change?
>
>
> That's something I would need to think about some more. I think you're
> heading in the right direction with your earlier suggestions.
Well, there were several suggestions (move all Apache:: methods into Apache
class or make the API use the class they live in). Which one do you like?
e.g. Apache::document_root living in Apache
vs Apache::ServerUtil::document_root living where it is now (Apache::ServerUtil)
> What would be nice is some type of die handler that would suggest to you
> which module to load if it can't find an "expected" method. That would
> make migrations, although still trial and error, at least much quicker...
Hrmm, have you looked at the porting docs?
http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded
http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__Programmatically
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Applications
http://perl.apache.org/docs/2.0/user/porting/porting.html#How_C_Apache__MP3__was_Ported_to_mod_perl_2_0
or you did and it doesn't do what you suggested above?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 01:15 -0800 1/16/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>At 01:05 -0800 1/16/04, Stas Bekman wrote:
>>>This is changing, take a look at: http://perl.apache.org/docs/2.0/api/
>>Still far from complete, last time I looked.
>Please look again. Most API is in place (though only skeletons which
>need further review and expansion).
Still far from complete ;-) Skeletons are nice to work with, but
don't tell you anything as a user.
>>> >The current setup (in the final stages of getting this going for
>>>a client right now) is _very_ >confusing.
>>>What do you mean? The thing I'm talking about?
>>Yep.
>So what would you suggest to change?
That's something I would need to think about some more. I think
you're heading in the right direction with your earlier suggestions.
What would be nice is some type of die handler that would suggest to
you which module to load if it can't find an "expected" method. That
would make migrations, although still trial and error, at least much
quicker...
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 01:05 -0800 1/16/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> At 15:50 -0800 1/15/04, Stas Bekman wrote:
>>>
>>>> I'm actually worried more about the users who have moved to mp2
>>>> already and would like to try not to break their code if possible.
>>>
>>> I think those users are used to making changes and living with not so
>>> well documented (different) features.
>>
>> This is changing, take a look at: http://perl.apache.org/docs/2.0/api/
>
>
> Still far from complete, last time I looked.
Please look again. Most API is in place (though only skeletons which need
further review and expansion).
>> >The current setup (in the final stages of getting this going for a
>> client right now) is _very_ >confusing.
>> What do you mean? The thing I'm talking about?
>
>
> Yep.
So what would you suggest to change?
>>> Getting file uploads working with libapreq without segfaults requires
>>> quite some testing... ;-)
>>
>> Well, that's a different story. You are talking about libapreq2, right?
>
>
> Yep, apart from bleeding edge, this is also cutting edge with real (tm)
> blood. ;-)
;)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 01:05 -0800 1/16/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>At 15:50 -0800 1/15/04, Stas Bekman wrote:
>>>I'm actually worried more about the users who have moved to mp2
>>>already and would like to try not to break their code if possible.
>>I think those users are used to making changes and living with not
>>so well documented (different) features.
>This is changing, take a look at: http://perl.apache.org/docs/2.0/api/
Still far from complete, last time I looked.
> >The current setup (in the final stages of getting this going for a
>client right now) is _very_ >confusing.
>What do you mean? The thing I'm talking about?
Yep.
>>Getting file uploads working with libapreq without segfaults
>>requires quite some testing... ;-)
>Well, that's a different story. You are talking about libapreq2, right?
Yep, apart from bleeding edge, this is also cutting edge with real
(tm) blood. ;-)
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 15:50 -0800 1/15/04, Stas Bekman wrote:
>
>>> well, I feel less strongly about this than you do. the few methods that
>>> live in Apache:: land are small compared to all the other adjustments
>>> users
>>> are already required to make.
>>
>> I'm actually worried more about the users who have moved to mp2
>> already and would like to try not to break their code if possible.
>
>
> I think those users are used to making changes and living with not so
> well documented (different) features.
This is changing, take a look at: http://perl.apache.org/docs/2.0/api/
> As long as it is clear what needs
> to be changed, I don't think it would be such a problem.
> It's the price of working on the bleeding edge, I think.
Thanks for the comment, Liz.
> The current setup (in the final stages of getting this going for a
> client right now) is _very_ confusing.
What do you mean? The thing I'm talking about?
> Getting file uploads working
> with libapreq without segfaults requires quite some testing... ;-)
Well, that's a different story. You are talking about libapreq2, right?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 15:50 -0800 1/15/04, Stas Bekman wrote:
>>well, I feel less strongly about this than you do. the few methods that
>>live in Apache:: land are small compared to all the other adjustments users
>>are already required to make.
>I'm actually worried more about the users who have moved to mp2
>already and would like to try not to break their code if possible.
I think those users are used to making changes and living with not so
well documented (different) features. As long as it is clear what
needs to be changed, I don't think it would be such a problem.
It's the price of working on the bleeding edge, I think.
The current setup (in the final stages of getting this going for a
client right now) is _very_ confusing. Getting file uploads working
with libapreq without segfaults requires quite some testing... ;-)
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>Please take a look at this new manpage
>>http://perl.apache.org/docs/2.0/api/Apache.html
>>
>>This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was
>>OK to have functions like Apache::current_callback() because almost
>>everything was preloaded. I don't think it's OK in mp2. It's absolutely
>>not obvious which module needs to be loaded to get this API, and most
>>people will try to load Apache, and it won't do the trick.
>
>
> well, I agree with you about the Apache:: namespace. but the "not obvious"
> part applies to lots of other things as well - it's also "absolutely not
> obvious" that you need to load Apache::RequestUtil to get $r->dir_config to
> work :)
Right, but it make certain sense, as it contains Apache::Request in it, so
it's easier to grok and it's somewhat intuitive (e.g. io methods belonging to
the IO class, and slot accessor methods belonging to the Rec class (assuming
you intimately know the C record struct.
Whereas Apache::foo makes little sense at all.
>>The only obvious need-to-keep is Apache->server,
>
>
> if we're going to keep Apache->server around then I don't see a reason for
> changing other Apache:: class methods/functions - either remove the Apache
> namespace completely, or make it more intuitive by creating a real Apache
> class (.pm, .xs and other required glue) where all these obscure methods live.
it could be an idea. but we need to give it some better thought. Or may be ask
Doug's reasoning for this choice. He promised to give one long long time ago,
but never did I think.
>>or do you think it's OK the way things are right now? The manpage
>>suggests to use
>>http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html to figure
>>what needs to be loaded, but it's not so intuitive.
>
>
> MethodLookup is really sweet, but it's not intuitive that you need a
> separate module to tell you what to load.
Not a module but a command line run. Actually, since we already have mp2bug
and mp2doc utils. I'm thinking to make ModPerl/MethodLookup more intuitive and
add 3 more utils: mp2method, mp2module, mp2object to perform the equivalent of:
% perl -MApache2 -MModPerl::MethodLookup -e print_method
% perl -MApache2 -MModPerl::MethodLookup -e print_module
% perl -MApache2 -MModPerl::MethodLookup -e print_object
just like we have the cpan utility vs.
% perl -MCPAN -eshell
This will make it much more accessible/useful.
>>The only real problem with this change suggestion is backwards
>>compatibility, which is nice to keep small.
>
>
> well, I feel less strongly about this than you do. the few methods that
> live in Apache:: land are small compared to all the other adjustments users
> are already required to make.
I'm actually worried more about the users who have moved to mp2 already and
would like to try not to break their code if possible.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] killing the ghost Apache:: usage?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Please take a look at this new manpage
> http://perl.apache.org/docs/2.0/api/Apache.html
>
> This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was
> OK to have functions like Apache::current_callback() because almost
> everything was preloaded. I don't think it's OK in mp2. It's absolutely
> not obvious which module needs to be loaded to get this API, and most
> people will try to load Apache, and it won't do the trick.
well, I agree with you about the Apache:: namespace. but the "not obvious"
part applies to lots of other things as well - it's also "absolutely not
obvious" that you need to load Apache::RequestUtil to get $r->dir_config to
work :)
>
> Why not replace:
[snip]
> The only obvious need-to-keep is Apache->server,
if we're going to keep Apache->server around then I don't see a reason for
changing other Apache:: class methods/functions - either remove the Apache
namespace completely, or make it more intuitive by creating a real Apache
class (.pm, .xs and other required glue) where all these obscure methods live.
> which can really be made a constant too.
I hadn't considered that, but you're absolutely right.
>
> or do you think it's OK the way things are right now? The manpage
> suggests to use
> http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html to figure
> what needs to be loaded, but it's not so intuitive.
MethodLookup is really sweet, but it's not intuitive that you need a
separate module to tell you what to load.
>
> The only real problem with this change suggestion is backwards
> compatibility, which is nice to keep small.
well, I feel less strongly about this than you do. the few methods that
live in Apache:: land are small compared to all the other adjustments users
are already required to make.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org