On tisdag, juni 4, 2002, at 05:22 , Alessandro Forghieri wrote:
> Greetings.
>
> I am hitting a complex Registry application with a number of almost
> simultaneous, long running requests
>
> (WinNT SP6 - VC++6 SP3 - perl5.8.0 RC1 - latest dev snapshot for
> modperl -
> httpd-2.0_20020530041218.
On Wed, 5 Jun 2002, Gerald Richter wrote:
> So for mod_perl is maybe always safe to say $mod_perl::VERSION >= 1.99 if
> $mod_perl::VERSION is a number and will never be a string. The regex thing
> is just precaution, because of bad experinces in the past.
As long as we only put letters at the en
>
> split? regex? huh?
>
> if ($mod_perl::VERSION >= 1.99) {
> #this is 2.x
> }
> else {
>#this is 1.x
> }
>
One the one side you are right, but I had some bad experiences with doing
floating point comparisons on version numbers. The one thing was, that due
to locale settings your decim
On Tue, 4 Jun 2002, R Blake wrote:
> doug,
>
> it turns out that the troubles building modperl2 on OSX (at least for me
> ) turned out not to be (directly) PERL options related, but rather
> required an update to libtool-1.4d ..
>
> i've now successsfully built modperl2 (_200205311630
On Tue, 4 Jun 2002, Gerald Richter wrote:
> $mod_perl::VERSION returns 1.9903, which is the same or similar then
> $ENV{MOD_PERL} which I using right now, but you need to split it with a
> regex and compare, and a 1 before the point is mod_perl 2 if after the point
> it start with 99, not ver
>
> Gerald, I've started:
>
http://perl.apache.org/release/docs/2.0/devel/porting_from_1.x/porting_from_
1.x.html
> which already covers some of the porting bits (like $mod_perl::VERSION).
$mod_perl::VERSION returns 1.9903, which is the same or similar then
$ENV{MOD_PERL} which I using right now,
I wrote some basic pod for Apache::Log, but I'm not sure whether to
document all the logging methods in Apache::Log or to move those related
to $r to the Apache::RequestRec pod and those related to $s to the
Apache::ServerRec pod.
Should we document the methods in the packages they were instal
doug,
it turns out that the troubles building modperl2 on OSX (at least for me ) turned out not to be (directly) PERL options related, but rather required an update to libtool-1.4d ..
i've now successsfully built modperl2 (_20020531163044 ) on OSX 10.1.4 Server .. to get there req'd:
On Tue, 4 Jun 2002, Stas Bekman wrote:
> Should PerlFreshRestart be allowed then as NOOP so the same config can
> be used for both without IfDefine conditioning?
would rather not, as it only applies to 1.x when modperl is linked static
and has known issues even with that. it should probably
On Tue, 4 Jun 2002, Alessandro Forghieri wrote:
> perl_clone_host(PerlInterpreter* proto_perl, UV flags) {
this will only be called if the number of concurrent requests is >
PerlInterpStart. i can look into the problem later, but in the meantime
would be interesting to see how things handle i
Most likely mod_perl 2.0 versioning will be using triplets (2.0.xx), and
even though that wasn't the case with the first mod_perl generation,
please try to refer to 1.x as 1.0 and 2.0.xx as 2.0 in the docs. This
convention makes the text easier to read, especially in the text which
is full of
On Wed, 5 Jun 2002, Stas Bekman wrote:
> you said that subs attributes work in 1.x and 2.x. But if 1.x is running
> with perl 5.005_3 the subs attrs won't work. This is the part that I
> don't understand. As Herbert later said he is actually developing for 1.x.
i said:
>> one needs at least 5
Doug MacEachern wrote:
> On Tue, 4 Jun 2002, Stas Bekman wrote:
>
>
>>[EMAIL PROTECTED] wrote:
>>
>>
>>> -C - is always set to something like: C
>>> +C - is set to C for compatibility
>>> +with mod_perl 1.x. The C environment variable has existed
>>> +since 1.17 and is recommended over check
Doug MacEachern wrote:
> On Wed, 5 Jun 2002, Stas Bekman wrote:
>
>
>>That's why I couldn't understand this comment of yours:
>
>
> i don't understand what you don't understand.
you said that subs attributes work in 1.x and 2.x. But if 1.x is running
with perl 5.005_3 the subs attrs won't wo
On Wed, 5 Jun 2002, Stas Bekman wrote:
> That's why I couldn't understand this comment of yours:
i don't understand what you don't understand.
> > also, this needs to be:
> >
> > sub trans : method {
> >
> > which works with both 1.x and 2.x
>
> Did you mean something else?
no.
On Tue, 4 Jun 2002, Stas Bekman wrote:
> [EMAIL PROTECTED] wrote:
>
> > -C - is always set to something like: C
> > +C - is set to C for compatibility
> > +with mod_perl 1.x. The C environment variable has existed
> > +since 1.17 and is recommended over checking the contents of
> > +C.
Doug MacEachern wrote:
> On Tue, 4 Jun 2002, Stas Bekman wrote:
>
>
>>5.005_03 inclusive?
>
>
> one needs at least 5.6.0 to run 2.0
> not concerned that < 5.6.0 has no support for subroutine attributes.
That's why I couldn't understand this comment of yours:
> also, this needs to be:
>
>
+1 on removing it.
On Tue, 4 Jun 2002, Stas Bekman wrote:
> from include/http_log.h
>
> /* APLOG_NOERRNO is ignored and should not be used. It will be
> * removed in a future release of Apache.
> */
> #define APLOG_NOERRNO (APLOG_LEVELMASK + 1)
>
> we should probably remove it fro
On Tue, 4 Jun 2002, Ask Bjoern Hansen wrote:
>
> with the latest httpd from cvs I get the following;
>
> -c modperl_filter.c && mv modperl_filter.o modperl_filter.lo
> cc -I/home/ask/ap/modperl-2.0/src/modules/perl -I/home/ask/ap/modperl-2.0/xs
>-I/home/ask/apache2/include -D_REENTRANT -D_GNU_
On Tue, 4 Jun 2002, Herbert Rosmanith wrote:
> I am using httpd-2.0.36
>
> gdb says:
> (gdb) bt
> #0 0x40166728 in strcmp () from /lib/libc.so.6
...
this should be fixed in modperl cvs now. problem was modperl added a
-DMODPERL2 during the pre_config phase, which only happens once, then
m
On Tue, 4 Jun 2002, Stas Bekman wrote:
> 5.005_03 inclusive?
one needs at least 5.6.0 to run 2.0
not concerned that < 5.6.0 has no support for subroutine attributes.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Doug MacEachern wrote:
> On Tue, 4 Jun 2002, Stas Bekman wrote:
>
>
>>BTW, Gerald, if you are using compat, you can still use the 1.0's
>>Apache::Registry. So you don't really need to conditional.
>
>
> he does if 1.x is not installed.
True. I didn't think there was a possibility of not hav
On Tue, 4 Jun 2002, Stas Bekman wrote:
> BTW, Gerald, if you are using compat, you can still use the 1.0's
> Apache::Registry. So you don't really need to conditional.
he does if 1.x is not installed.
-
To unsubscribe, e-mai
Greetings.
I am hitting a complex Registry application with a number of almost
simultaneous, long running requests
(WinNT SP6 - VC++6 SP3 - perl5.8.0 RC1 - latest dev snapshot for modperl -
httpd-2.0_20020530041218.tar.gz for apache - everything built debug - a few
date.t tests fail on nmake t
from include/http_log.h
/* APLOG_NOERRNO is ignored and should not be used. It will be
* removed in a future release of Apache.
*/
#define APLOG_NOERRNO (APLOG_LEVELMASK + 1)
we should probably remove it from constants and where it's used (in
aplog.pm test)
___
Herbert Rosmanith wrote:
>>+sub log_error {
>>+Apache->server->log_error(@_);
>>+}
>>+
>
>
> yep, I have alread done this. however, with the latest cvs, apache-2
> segfaults:
>
> [Tue Jun 04 13:24:48 2002] [error] > trans
> [Tue Jun 04 13:24:48 2002] [error] > SubEnvironment
> [
> +sub log_error {
> +Apache->server->log_error(@_);
> +}
> +
yep, I have alread done this. however, with the latest cvs, apache-2
segfaults:
[Tue Jun 04 13:24:48 2002] [error] > trans
[Tue Jun 04 13:24:48 2002] [error] > SubEnvironment
[Tue Jun 04 13:24:48 2002] [error] > trans
[EMAIL PROTECTED] wrote:
> -C - is always set to something like: C
> +C - is set to C for compatibility
> +with mod_perl 1.x. The C environment variable has existed
> +since 1.17 and is recommended over checking the contents of
> +C.
shouldn't it be better to have GATEWAY_INTERFACE doc
Herbert Rosmanith wrote:
>>You should use:
>>
>> Apache->server->log_error("test3.pm::BEGIN");
>>
>>if you don't have $r, or $r->log_error() inside the handler.
>>
>>I don't think this is any different from 1.0
>
>
> it is, because with 1.0, I can happily use "Apache::log_error", which
> I h
Herbert Rosmanith wrote:
>>Herbert Rosmanith wrote:
>>
>You want to load Apache::RequestRec and then it'll show up.
>>>another issue: when I "use Apache::RequestRec();" the module
>>>will not start under modperl-1.0.
>>
>>why should it? It's a 2.0 module.
>
>
>
> you told me to use it
> Herbert Rosmanith wrote:
> >>>You want to load Apache::RequestRec and then it'll show up.
> >>
> >
> > another issue: when I "use Apache::RequestRec();" the module
> > will not start under modperl-1.0.
>
> why should it? It's a 2.0 module.
you told me to use it ..
let me explain: I wrot
>
> You should use:
>
> Apache->server->log_error("test3.pm::BEGIN");
>
> if you don't have $r, or $r->log_error() inside the handler.
>
> I don't think this is any different from 1.0
it is, because with 1.0, I can happily use "Apache::log_error", which
I have done at numerous places.
>
Herbert Rosmanith wrote:
>>>You want to load Apache::RequestRec and then it'll show up.
>>
>
> another issue: when I "use Apache::RequestRec();" the module
> will not start under modperl-1.0.
why should it? It's a 2.0 module. If you want to have your startup file
work for both consider using:
Herbert Rosmanith wrote:
>>Herbert, this is already documented here:
>>http://perl.apache.org/release/docs/2.0/user/compat/compat.html#C_log_reason___
>
>
>
> it says:
> log_reason() has been replaced with a set of dedicated functions:
> Apache::RequestRec::log_error(), Apache::ServerRec::
> > You want to load Apache::RequestRec and then it'll show up.
>
another issue: when I "use Apache::RequestRec();" the module
will not start under modperl-1.0.
/herp
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additiona
> Herbert, this is already documented here:
> http://perl.apache.org/release/docs/2.0/user/compat/compat.html#C_log_reason___
it says:
log_reason() has been replaced with a set of dedicated functions:
Apache::RequestRec::log_error(), Apache::ServerRec::log_error(),
Apache::Log::info() and
Herbert Rosmanith wrote:
> by the way, I downloaded the latest snapshot from perl.apache.org
> (modperl-2.0_20020604042309.tar.gz), but Apache::log_error was still
> undefined there. Can I use these snapshots or would I have to use
> "cvs"? (I am behind a firewall which doesnt allow me to do cvs
with the latest httpd from cvs I get the following;
-c modperl_filter.c && mv modperl_filter.o modperl_filter.lo
cc -I/home/ask/ap/modperl-2.0/src/modules/perl -I/home/ask/ap/modperl-2.0/xs
-I/home/ask/apache2/include -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -I/usr/local/inc
> On Mon, 3 Jun 2002, Herbert Rosmanith wrote:
>
> > aha. I had changed that to "use Apache2::APR::Table();" and it worked.
>
> you shouldn't have to do that. do you configure:
> PerlModule Apache2
> PerlModule Apache::compat
> ?
yes, I do.
> > $r->lookup_uri;
> >
> > seems to be misi
Doug MacEachern wrote:
> On Mon, 3 Jun 2002, Herbert Rosmanith wrote:
>
>
>>sub trans($$) {
>
>
> also, this needs to be:
>
> sub trans : method {
>
> which works with both 1.x and 2.x
5.005_03 inclusive?
__
Stas Bekman
Doug MacEachern wrote:
> On Tue, 4 Jun 2002, Stas Bekman wrote:
>
>
>>Meaning that we do want to be compatible with 1.x?
>
>
> yes, wherever possible when it doesn't cause more trouble than it is
> worth.
Should PerlFreshRestart be allowed then as NOOP so the same config can
be used for bo
Doug MacEachern wrote:
> On Tue, 4 Jun 2002, Stas Bekman wrote:
>
>
>>I haven't finished porting the registry family. When I'm done there will
>>be no need for Apache::compat to run ModPerl::Registry. Why would you need
>>to know whether you are running under Apache::Registry or
>>ModPerl::Regi
>>The otherthing is the test suite, which need to know which version we are
>>using and startup.pl need to decide to load Apache::Registry or
>>ModPerl::Registry. I currently check $ENV{MOD_PERL}, is there a better way
>>to decide, if we are running under mod_perl, something like
>>$ModPerl::Majo
43 matches
Mail list logo
