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 hashes
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 *sv =
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.
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))
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
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:
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
from the
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
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)
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
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
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 is
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? I
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 of
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 running
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
it
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.
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_perl
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
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
20 matches
Mail list logo
