Thanks, all, for the prompt attention. I will update my coding habits
accordingly :)
Cheers
On Wed, 10 Dec 2003, Stas Bekman wrote:
> I've pinged Doug and the final verdict is this:
>
>The print-a-scalar-reference feature is now deprecated. There are
>known bugs when using it and it's n
I've pinged Doug and the final verdict is this:
The print-a-scalar-reference feature is now deprecated. There are
known bugs when using it and it's not supported by mod_perl 2.0. If
you have a scalar reference containing a string to be printed,
dereference it before sending it to print.
It
Stas Bekman wrote:
> Actually I think the current code has another bug. If you do:
>
>my $x = 1;
>print(\$x);
>
> I'd expect it to print 1 and it won't, because $x is IV and not PV. So I'd
> completely drop any checks for PV, and coerce any reference into PV, like so:
>
> SV *s
Rafael Garcia-Suarez wrote:
Stas Bekman wrote:
But you forget that nobody is going pass SVt_PVBM scalar to print(). Why would
they? Do you have a concrete example of someone trying to send a scalar of
type > PV to print? Rafael, can you think of such an example?
Reference to magic scalars ? (\
Stas Bekman wrote:
>
> But you forget that nobody is going pass SVt_PVBM scalar to print(). Why would
> they? Do you have a concrete example of someone trying to send a scalar of
> type > PV to print? Rafael, can you think of such an example?
Reference to magic scalars ? (\$1)
to arrays ? to ha
Frank Maas 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?
Gee... not on a technical, but more on a philosophical side: is this
a wise thing to do? It means that you have to be damm sure that someone
(a)
> 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?
Gee... not on a technical, but more on a philosophical side: is this
a wise thing to do? It means that you have to be damm sure that someone
(a) can find out
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,
> 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
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.
--
> 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
> 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
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)
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
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))
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 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. However I
have come across a situati
35 matches
Mail list logo
