Re: Why does $r-print() dereference its arguments?
On Thu, 4 May 2000, Jeffrey W. Baker wrote:
Not strictly for debugging, but for introspection. I was toying with
a module that pokes around inside the perlguts of a running mod_perl
server and makes some nice displays out of them. Nothing for
production/money mind you, just amusement.
i did have reservations when adding the stunt, but i figured the chances
of somebody printing a $reference on purpose, which was not interpolated
in another string already were pretty slim. seems you're the first to
notice in the two years since the "feature" was added :)
btw, just to be clear, $strings passed to $r-print() are not copied, they
are passed by reference, just like any argument to a subroutine. but
most subroutines copy the arguments into their own variables, e.g.:
sub foo {
my ($header, $body, $footer) = @_;
so the idea was that you could pass around references to strings, which
end up being passed to $r-print, without having to worry about
dereferencing.
Here is a patch I made against the documentation in Apache.pm. Actually,
I had to attach it because it was wrapping.
thanks!
Re: Why does $r-print() dereference its arguments?
On Wed, 3 May 2000, Jeffrey W. Baker wrote: Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. it only pulls that stunt for strings. assuming you're only printing the reference for debugging purposes, just stringify it first: my $foo = \"bar"; print "$foo"; or, geoff's trick: my $foo = "bar"; print \$foo . ""; do you need to avoid this feature for something other than debugging?
Re: Why does $r-print() dereference its arguments?
On Wed, 3 May 2000, Doug MacEachern wrote: On Wed, 3 May 2000, Jeffrey W. Baker wrote: Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. it only pulls that stunt for strings. assuming you're only printing the reference for debugging purposes, just stringify it first: my $foo = \"bar"; print "$foo"; or, geoff's trick: my $foo = "bar"; print \$foo . ""; do you need to avoid this feature for something other than debugging? Not strictly for debugging, but for introspection. I was toying with a module that pokes around inside the perlguts of a running mod_perl server and makes some nice displays out of them. Nothing for production/money mind you, just amusement. Here is a patch I made against the documentation in Apache.pm. Actually, I had to attach it because it was wrapping. Regards, Jeffrey --- Apache.pm.orig Thu May 4 08:20:59 2000 +++ Apache.pm Thu May 4 08:31:31 2000 @@ -911,7 +911,21 @@ =item $r-print( @list ) This method sends data to the client with C$r-Egtwrite_client, but first -sets a timeout before sending with C$r-Egthard_timeout. +sets a timeout before sending with C$r-Egthard_timeout. This method is +called instead of CORE::print when you use print() in your mod_perl programs. + +This method treats scalar references specially. If an item in @list is a +scalar reference, it will be dereferenced before printing. This is a +performance optimization which prevents unneeded copying of large strings, +and it is subtly different from Perl's standard print() behavior. + +Example: + +$foo = \"bar"; print($foo); + +The result is "bar", not the "SCALAR(0xDEADBEEF)" you might have expected. If +you really want the reference to be printed out, force it into a scalar +context by using print(scalar($foo)). =item $r-send_fd( $filehandle )
Re: Why does $r-print() dereference its arguments?
On Wed, 3 May 2000, Jeffrey W. Baker wrote: Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. That's a performance improvement, see: http://perl.apache.org/guide/porting.html#Apache_print_and_CORE_print_ __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Why does $r-print() dereference its arguments?
"Jeffrey W. Baker" [EMAIL PROTECTED] writes:
Apache::print() dereferences its arguments. For example, this code:
my $foo = "bar";
$r-print(\$foo);
prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
explain the purpose of this behavior, or is it a misfeature? In my case,
this is not the desired behavior.
If I recall correctly, this is a performance issue. If you have a
large string you want to print, sending a reference will result in
less data copying etc. I don't know how much it pays off, but it is
an intended effect.
You could try something like:
$r-print("@{[\$foo]}");
Chip
--
Chip Turner [EMAIL PROTECTED]
ZFx, Inc. www.zfx.com
PGP key available at wwwkeys.us.pgp.net
Re: Why does $r-print() dereference its arguments?
"Jeffrey" == Jeffrey W Baker [EMAIL PROTECTED] writes:
Jeffrey Apache::print() dereferences its arguments. For example, this code:
Jeffrey my $foo = "bar";
Jeffrey $r-print(\$foo);
Jeffrey prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
Jeffrey explain the purpose of this behavior, or is it a misfeature? In my case,
Jeffrey this is not the desired behavior.
You can always call $r-print(\\$foo); :)
As in, $r-print(map { \$_ } @list) will work as your print, always.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Why does $r-print() dereference its arguments?
interesing behavior - print behaves the same way... however, when you concat the reference to another scalar things work right... $r-print($foo.\$foo); yields: fooSCALAR(0xXWHOOPSX) --Geoff -Original Message- From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 03, 2000 1:37 PM To: [EMAIL PROTECTED] Subject: Why does $r-print() dereference its arguments? Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. -jwb
RE: Why does $r-print() dereference its arguments?
On Wed, 3 May 2000, Geoffrey Young wrote: interesing behavior - print behaves the same way... http://perl.apache.org/guide/porting.html#Apache_print_and_CORE_print_ Under mod_perl CORE::print() will redirect its data to Apache::print() since the STDOUT filehandle is tied to the Apache module. however, when you concat the reference to another scalar things work right... $r-print($foo.\$foo); yields: fooSCALAR(0xXWHOOPSX) --Geoff -Original Message- From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 03, 2000 1:37 PM To: [EMAIL PROTECTED] Subject: Why does $r-print() dereference its arguments? Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. -jwb __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: Why does $r-print() dereference its arguments?
-Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 03, 2000 2:07 PM To: Geoffrey Young Cc: mod_perl list Subject: RE: Why does $r-print() dereference its arguments? On Wed, 3 May 2000, Geoffrey Young wrote: interesing behavior - print behaves the same way... http://perl.apache.org/guide/porting.html#Apache_print_and_CORE_print_ the guide is getting so big these days, it's hard to keep up with all the new developments. Or maybe that entered a few versions ago :) It's along way from the mini-guide that got me started... Under mod_perl CORE::print() will redirect its data to Apache::print() since the STDOUT filehandle is tied to the Apache module. yeah, I thought something like that was happening, but I wasn't sure about the mechanism - I recently saw that Apache::Filter will intercept print() but not $r-print(), so I wasn't sure what was going on internally... thanks --Geoff however, when you concat the reference to another scalar things work right... $r-print($foo.\$foo); yields: fooSCALAR(0xXWHOOPSX) --Geoff -Original Message- From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 03, 2000 1:37 PM To: [EMAIL PROTECTED] Subject: Why does $r-print() dereference its arguments? Apache::print() dereferences its arguments. For example, this code: my $foo = "bar"; $r-print(\$foo); prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone explain the purpose of this behavior, or is it a misfeature? In my case, this is not the desired behavior. -jwb __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: Why does $r-print() dereference its arguments?
-Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 03, 2000 2:23 PM To: Geoffrey Young Cc: mod_perl list Subject: RE: Why does $r-print() dereference its arguments? -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 03, 2000 2:07 PM To: Geoffrey Young Cc: mod_perl list Subject: RE: Why does $r-print() dereference its arguments? On Wed, 3 May 2000, Geoffrey Young wrote: interesing behavior - print behaves the same way... http://perl.apache.org/guide/porting.html#Apache_print_and_CORE_print_ the guide is getting so big these days, it's hard to keep up with all the new developments. Or maybe that entered a few versions ago :) It's along way from the mini-guide that got me started... That's correct. It was added in the last release CHANGES: 04.09.2000 ver 1.22 * porting: added: "Apache::print() and CORE::print()" (Doug) Well, it's been mini-guide, then it became just guide, now I'm going to call it giant-guide :) Sorry about the size. I hear woes when there is no documentation, and as well when there is too much of it... go figure out :) no apologies necessary - more docs, and sharing of knowledge, are always good things... Under mod_perl CORE::print() will redirect its data to Apache::print() since the STDOUT filehandle is tied to the Apache module. yeah, I thought something like that was happening, but I wasn't sure about the mechanism - I recently saw that Apache::Filter will intercept print() but not $r-print(), so I wasn't sure what was going on internally... Of course, it's because the two are basically the same under mod_perl, so it doesn't matter which one you pick to intercept. Well, only one way... $r-print() won't call CORE::print(). oh, I see it now (duh!)... thanks --Geoff __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Why does $r-print() dereference its arguments?
On 3 May 2000, Chip Turner wrote:
"Jeffrey W. Baker" [EMAIL PROTECTED] writes:
Apache::print() dereferences its arguments. For example, this code:
my $foo = "bar";
$r-print(\$foo);
prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
explain the purpose of this behavior, or is it a misfeature? In my case,
this is not the desired behavior.
If I recall correctly, this is a performance issue. If you have a
large string you want to print, sending a reference will result in
less data copying etc. I don't know how much it pays off, but it is
an intended effect.
You could try something like:
$r-print("@{[\$foo]}");
Or I could just do $r-print(scalar(\$foo));, but that's not my point. My
point is Ewww. I just don't like the overloaded
interface. Does $r-print() take scalars, or references? If it takes
scalars, it shouldn't be dereferencing them. If there is a performance
need for passing references around instead of copying strings, that should
be a different method, perhaps print_ref(). It just seems more clean to
me. Is my mindset too C?
-jwb
Re: Why does $r-print() dereference its arguments?
At 11:56 AM 5/3/00 -0700, Jeffrey W. Baker wrote:
On 3 May 2000, Chip Turner wrote:
"Jeffrey W. Baker" [EMAIL PROTECTED] writes:
Apache::print() dereferences its arguments. For example, this code:
my $foo = "bar";
$r-print(\$foo);
prints "bar" instead of the expected SCALAR(0xDEADBEEF). Can anyone
explain the purpose of this behavior, or is it a misfeature? In my case,
this is not the desired behavior.
If I recall correctly, this is a performance issue. If you have a
large string you want to print, sending a reference will result in
less data copying etc. I don't know how much it pays off, but it is
an intended effect.
You could try something like:
$r-print("@{[\$foo]}");
Or I could just do $r-print(scalar(\$foo));, but that's not my point. My
point is Ewww. I just don't like the overloaded
interface. Does $r-print() take scalars, or references? If it takes
scalars, it shouldn't be dereferencing them. If there is a performance
need for passing references around instead of copying strings, that should
be a different method, perhaps print_ref(). It just seems more clean to
me. Is my mindset too C?
I prefer overloading that is documented. It makes things a lot easier to
remember one method name.
Otherwise, you have to be an expert who remembers common idioms like _ref
for references... otherwise, people would argue should it be called
ref_print, reference_print, print_ref, print_as_ref... Programmers have all
sorts of weird ways to name functions (if you've delved into other people's
source code) which I hate.
HOWEVER, I think a good argument for NOT overloading print() in this
particular case is that it is taking over CORE::print. This is contrary to
documented Perl behavior and is not backwards compatible then right? If
this is the case, then that seems suboptimal.
Also, I guess I could see the point that since print() is so well defined
in the core Perl, that people might expect Apache's print to operate
identically even if it is called directly. And therefore, the behavior
should not change from CORE::print anyway.
So in summary, I think I am saying that I vote to support your desire
reluctantly because I am generally a fan of overloading (but not in this
case if I am interpreting the facts correctly).
Of course, it may be too late because there may be a load of code that is
dependent on this "Performance improvment". So it may be a moot point anyway.
Later,
Gunther
__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
