Geoffrey Young wrote:
Let's do this: try to fix it in the next version. If someone discovers
that we broke their code we will revert it. How does it sound?
well, of course - we wouldn't leave broken code laying around just for fun.
the issue really is how important you think it is to be stable,
It still fails at the same place.
Thanks,
Rita
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 02, 2003 6:18 PM
To: THELLA,RITA (HP-Cupertino,ex3)
Cc: '[EMAIL PROTECTED]'
Subject: Re: make test errors (modperl 1.99_11 and perl 5.8.2)
THELLA,RITA (H
THELLA,RITA (HP-Cupertino,ex3) wrote:
Here is the extra.conf:
[...]
it'd be better to attach the file, rather than inlining it as your mail-client
has wrapped up the lines, but you couldn't have known ;) But let's assume that
it's not wrapped in the original.
SetHandler perl-script
Opt
> Let's do this: try to fix it in the next version. If someone discovers
> that we broke their code we will revert it. How does it sound?
well, of course - we wouldn't leave broken code laying around just for fun.
the issue really is how important you think it is to be stable, and exactly
what t
> Rafael Garcia-Suarez suggested to:
>
> - SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
> + SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
>
> Jonathan, have you verified that it fixes your problem?
Yes. I just tried this change with Apache/1.3.27 (Unix) mod_perl/1.27
m
Geoffrey Young wrote:
[..]
- SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
+ SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
+1 to fix this bug.
[...]
but do you really want to derefernce a SVt_PVFM? the implications
here are
far beyond my reach.
formats don't work with mod_
Stas Bekman wrote:
> Rafael Garcia-Suarez suggested to:
>
> - SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
> + SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
>
> +1 to fix this bug.
>
> Jonathan, have you verified that it fixes your problem?
>
> Geoffrey Young then s
Here is the extra.conf:
---
# WARNING: this file is generated (from
/proj/middleware/rthella/mod_perl-1.99_11/t/conf/extra.conf.in), do not edit
# 01:
/proj/middleware/rthella/mod_perl-1.99_11/Apache-Test/lib/Apache/TestConfig.
pm:746
# 02:
/proj/middleware/rthella/mod_perl-1
Rafael Garcia-Suarez suggested to:
- SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) == SVt_PV);
+ SV *sv = SvROK(ST(i)) && (SvTYPE(SvRV(ST(i))) >= SVt_PV);
+1 to fix this bug.
Jonathan, have you verified that it fixes your problem?
Geoffrey Young then said:
> but do you really want to derefern
Ged Haywood wrote:
Ged, please don't do that again. Imagine others starting to post this kind of
requests here. We ask people not to post general perl questions here and you
post a hardware sales request... That's just plain impolite to people.
--
Jay R. Ashworth wrote:
On Tue, Dec 02, 2003 at 12:22:10PM -0800, THELLA,RITA (HP-Cupertino,ex3) wrote:
I installed perl 5.8.2 and Apache 2.0.48(built from src using perl 5.8.0). I
downloaded modperl 1.99_11 and ran
perl Makefile.PL MP_GENERATE_XS=1 MP_USE_DSO=1
MP_APXS=/opt/hpws/apache/bin/apxs \
On Tue, Dec 02, 2003 at 12:22:10PM -0800, THELLA,RITA (HP-Cupertino,ex3) wrote:
> I installed perl 5.8.2 and Apache 2.0.48(built from src using perl 5.8.0). I
> downloaded modperl 1.99_11 and ran
>
> perl Makefile.PL MP_GENERATE_XS=1 MP_USE_DSO=1
> MP_APXS=/opt/hpws/apache/bin/apxs \
>
Hi,
I installed perl 5.8.2 and Apache 2.0.48(built from src using perl 5.8.0). I
downloaded modperl 1.99_11 and ran
perl Makefile.PL MP_GENERATE_XS=1 MP_USE_DSO=1
MP_APXS=/opt/hpws/apache/bin/apxs \
PREFIX=/opt/hpws/apache/lib/perl
make test is failing with the following error messag
> But anyway, just thought I'd comment that the reason I think most mod_perl
> developers would think to use that functionality would be memory, rather
> than speed. Pretty much all of our mod_perl servers are memory bound
> rather than CPU bound, and are "fast enough" without much optimization.
T
Hello,
JF>Measurable, but also negligable (code below):
JF>
JF>Benchmark: timing 5 iterations of ref, val...
JF> ref: 3 wallclock secs ( 2.72 usr + 0.12 sys = 2.84 CPU) @ 17605.63/s (n=5)
JF> val: 7 wallclock secs ( 6.05 usr + 0.18 sys = 6.23 CPU) @ 8025.68/s (n=5)
So, we use
Thanks for the info. It all makes some sort of sense :)
Jonathan Field
On Tue, 2 Dec 2003, Rafael Garcia-Suarez wrote:
> Jonathan Field wrote:
> > I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
> > subsequent requests to a child -- indicating to me that the ref (and what
>
> My intuition tells me that the performance gain is not mesureable anyway.
Measurable, but also negligable (code below):
Benchmark: timing 5 iterations of ref, val...
ref: 3 wallclock secs ( 2.72 usr + 0.12 sys = 2.84 CPU) @ 17605.63/s (n=5)
val: 7 wallclock secs ( 6.05 usr + 0.
Jonathan Field wrote:
> I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
> subsequent requests to a child -- indicating to me that the ref (and what
> it was refering to) may have survived the request cycle? I guess would
> have expected a different ref, especially after runnin
Hi there,
On Tue, 2 Dec 2003, Jonathan Field wrote:
> I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
> subsequent requests to a child -- indicating to me that the ref (and what
> it was refering to) may have survived the request cycle?
> [snip]
> Just my thoughts as a curiou
Patricio Muñoz wrote:
Hi,
When execute the script the result is fine, but the display the next
messages in the browser:
Hola Mundo
OK
The server encountered an internal error or misconfiguration and was unable
to complete your request.
If you
> When I first started working with computers they used to say
> that the cost of the software was roughly equal to the cost
> of the hardware. Now they say that the cost of the hardware
> is roughly zero.
Aw gee - can I have some of that hardware that costs zero please.
Specifically a couple o
> I'm not sure what you mean here.
> Note that *variables* are lexically scoped, but not values.
I was surprised that the "SCALAR(0x8ca70e4)" output was identical on
subsequent requests to a child -- indicating to me that the ref (and what
it was refering to) may have survived the request cycle?
Jonathan Field wrote:
>
> I am curious why the feature is to be disabled in 2.x? Not questioning
> the judgement, but wondering if it was determined to not be a worthwhile
> performance gain? Or is it just too complex internally despite the gain?
My intuition tells me that the performance gain
Hi there,
On Tue, 2 Dec 2003, Jonathan Field wrote:
> I am curious why the feature is to be disabled in 2.x? Not questioning
> the judgement, but wondering if it was determined to not be a worthwhile
> performance gain?
I'm sure the performance impact is negligible. If you're looking for
perfo
If I may follow up --
I am curious why the feature is to be disabled in 2.x? Not questioning
the judgement, but wondering if it was determined to not be a worthwhile
performance gain? Or is it just too complex internally despite the gain?
I am always looking to squeeze the last bit of performace
On Tue, Dec 02, 2003 at 12:17:08PM -0300, Patricio Muñoz wrote:
> More information about this error may be available in the server error log.
> ---
>
> And error.log not display nothing
If you're using virtual hosts, remember tha tyou have *2* e
Ged Haywood wrote:
> I was talking about fixing a fault which is partly the result of a
> daft and deprecated feature which has caused confusion in the past.
Is it documented to be deprecated ? does it issue a deprecation warning ?
(ideally when warnings 'deprecated' is on with perl 5.6 or higher)
Hello there,
On Tue, 2 Dec 2003, [iso-8859-1] Patricio Muñoz wrote:
> When execute the script the result is fine [snip]
:)
No, the result was not fine...
> The server encountered an internal error or misconfiguration
...because this is part of the result. However you haven't given
anything l
Geoffrey Young wrote:
Ged Haywood wrote:
Shouldn't we in fact be changing something?
My view would be that the dereferencing facility should be removed
from the standard build but left as a non-default compilation option
for those that need it to support old code. A message to STDERR to
the e
Hi Geoff,
On Tue, 2 Dec 2003, Geoffrey Young wrote:
> the danger here is changing the stable tree willy nilly.
I was talking about fixing a fault which is partly the result of a
daft and deprecated feature which has caused confusion in the past.
Of course I thoroughly agree that changes to the s
Hi,
When execute the script the result is fine, but the display the next
messages in the browser:
Hola Mundo
OK
The server encountered an internal error or misconfiguration and was unable
to complete your request.
Please contact the server
Ged Haywood wrote:
> Hi all,
>
> On Tue, 2 Dec 2003, Geoffrey Young wrote:
>
>
>>it's fun to track this kind of stuff down, even
>>if we end up not changing anything :)
>
>
> Shouldn't we in fact be changing something?
>
> My view would be that the dereferencing facility should be removed
>
Geoffrey Young wrote:
> >>I think the issue is that after your manipulations $dataref is no longer a
> >>plain PV. I used Devel::Peek to look at $dataref before and after and it
> >>changes from a PV to PVMG. where this trips up mod_perl is in
> >>Apache::write_client:
> >>
> >>SV *sv = S
Rafael Garcia-Suarez wrote:
> Geoffrey Young wrote:
>
>>I think the issue is that after your manipulations $dataref is no longer a
>>plain PV. I used Devel::Peek to look at $dataref before and after and it
>>changes from a PV to PVMG. where this trips up mod_perl is in
>>Apache::write_client:
Hi all,
On Tue, 2 Dec 2003, Geoffrey Young wrote:
> it's fun to track this kind of stuff down, even
> if we end up not changing anything :)
Shouldn't we in fact be changing something?
My view would be that the dereferencing facility should be removed
from the standard build but left as a non-de
Geoffrey Young wrote:
> I think the issue is that after your manipulations $dataref is no longer a
> plain PV. I used Devel::Peek to look at $dataref before and after and it
> changes from a PV to PVMG. where this trips up mod_perl is in
> Apache::write_client:
>
> SV *sv = SvROK(ST(i))
my $uid = $s->uid;
my $gid = $s->gid;
> Include yes, but how should it be coded.
is apr_uid_current equivalent to the old s->server_uid/gid? if so, we could
open up part of APR::User.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/m
Jonathan Field wrote:
> Hi all,
>
> This is my first mod_perl bug report, so I'd like to start by thanking you
> all for your great work over the years.
>
> The problem I am experiencing involves passing a scalar reference (instead
> of a scalar) to $r->print(). It usually works as documented.
Hi!
On Tue, Dec 02, 2003 at 09:11:26AM +0100, Jon wrote:
>I wonder if there's any litrature or web pages anyone can recomend
> reading to learn more about what can be done with mod_perl to speed things
> up.
Try:
http://perl.apache.org/
http://perl.apache.org/docs/offsite/index.html
http
Hi,
I'm using mod_perl a bit but I get the feeling I'm using it too much like cgi perl, ie
not using as much caching, persistent connections etc as possible. I wonder if there's
any litrature or web pages anyone can recomend reading to learn more about what can be
done with mod_perl to speed th
40 matches
Mail list logo
