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
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> hi all
>>
>> joe schaefer suggested on modperl@ that having access to
>> apr_brigade_flatten
>> might be of use.
> I certainly have no objections to opening up the entire APR API if
> someone needs it. And most of the APR::(Brigade|Bucket) API is
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
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?
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
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 i
Geoffrey Young wrote:
[...]
Index: xs/APR/Brigade/APR__Brigade.h
===
RCS file: /home/cvspublic/modperl-2.0/xs/APR/Brigade/APR__Brigade.h,v
retrieving revision 1.4
diff -u -r1.4 APR__Brigade.h
--- xs/APR/Brigade/APR__Brigade.h 29 Mar 20
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 ne
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.
> >
> > Thi
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 advoc
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
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
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
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 obj
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.
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
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
--
On Mon, 2004-01-19 at 14:06, Geoffrey Young wrote:
> > [...]
> >
> > May be we should take this further and make Apache::Server what Apache::
> > is used to be: i.e., just the httpd accessors. And create
> > Apache::ServerRec similar to Apache::RequestRec which will give the
> > access to $s?
> >
On Wed, 2004-01-07 at 09:56, Stas Bekman wrote:
> Geoffrey Young wrote:
> [...]
Sorry for kicking in late on this thread, but lemme share my 0.02$
> I'm very unhappy about this change in Apache, but besides me everybody keeps
> quiet and doesn't complain/looking for solutions in the core of the
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.
Philippe M. Chiasson wrote:
On Wed, 2004-01-07 at 09:56, Stas Bekman wrote:
Geoffrey Young wrote:
[...]
Sorry for kicking in late on this thread, but lemme share my 0.02$
I'm very unhappy about this change in Apache, but besides me everybody keeps
quiet and doesn't complain/looking for soluti
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).
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 ju
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 "r
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
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
> Well, being a bit slanted on the security side, I agree with mandatory
> escaping of the error_logs, as annoying it might be for development
> reasons.
well, we've come up with a compromize in 2.1 - compile with
-DAP_UNSAFE_ERROR_LOG_UNESCAPED and the error_log will remain in its
unescaped form
Geoffrey Young wrote:
Well, being a bit slanted on the security side, I agree with mandatory
escaping of the error_logs, as annoying it might be for development
reasons.
well, we've come up with a compromize in 2.1 - compile with
-DAP_UNSAFE_ERROR_LOG_UNESCAPED and the error_log will remain in it
>> +if (rv == APR_SUCCESS) {
>> +return newSViv((int)length);
>> +}
>> +
>> +return &PL_sv_undef;
>> +}
>
>
> won't it be better to die if it fails and stick rv into [EMAIL PROTECTED] e.g. if you
> try to read a bucket which has no data? Just thinking aloud here, we
> have ma
Geoffrey Young wrote:
+if (rv == APR_SUCCESS) {
+return newSViv((int)length);
+}
+
+return &PL_sv_undef;
+}
won't it be better to die if it fails and stick rv into [EMAIL PROTECTED] e.g. if you
try to read a bucket which has no data? Just thinking aloud here, we
have many plac
Kailden K wrote:
1. Problem Description:
On AIX 4.3.3, for mod_perl version 1.99_12 (yesterday's CVS)
Compile seems to work but make test fails to load shared libraries,
outputting:
t/TEST -bugreport -verbose=0
/usr/local/apache2/bin/httpd -d /home/xxx/install-src/modperl-2.0/t -f
/home/xxx/
Rafael, did you have a chance to debug this? The context is below if you have
deleted the thread from 2 months ago.
Stas Bekman wrote:
Rafael Garcia-Suarez wrote:
Stas Bekman wrote:
mod_perl 1.99_10 on AIX 5.2 with the IBM vac compiler, using
perl 5.8.1 without ithreads, is mostly OK.
[...]
He
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
Elizabeth Mattijsen wrote:
At 10:15 -0800 1/12/04, Stas Bekman wrote:
Elizabeth Mattijsen wrote:
At 10:00 -0800 1/12/04, Stas Bekman wrote:
% perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
1})->detach for 1..1'
A thread exited while 2 threads were running.
Ah. That! That is con
Steve, Randy, can you please try with this patch. This is against the conf
file with:
PerlOptions +Parent
1;
Index: src/modules/perl/modperl_cmd.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retri
Another one to try (w/ and w/o last patch). As you realize I'm shooting in the
dark, trying to guess where the context could go wrong. Thanks.
Index: src/modules/perl/modperl_interp.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/p
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
Stas Bekman wrote:
Another one to try (w/ and w/o last patch). As you realize I'm shooting
in the dark, trying to guess where the context could go wrong. Thanks.
BTW, this one if it'll do anything should affect the PerlLoadModule faulty
scenario and not the 1 one.
Index: src/modules/perl/modperl
Stas Bekman wrote:
[...]
the reason I suggested a subclass was so that the rare people who
require nph scripts have an outlet, while the vast majority of users
are not
burdened with the overhead of checking for nph- scripts on every
request.
A quick index() call to check for "nph-" is not going
39 matches
Mail list logo
