Ged Haywood wrote:
Hello again Phil,
On Sat, 6 Dec 2003, Phil Rhoades wrote:
modperl_perl.c:226: `PL_rehash_seed' undeclared (first use in this function)
I think this is probably because you're using Perl 5.9.0 - if you look
at the bottom of src/modules/perl/modperl_perl.c you'll see
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 =
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))
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)
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
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
I can't build Apache::SubProcess 0.03 on AIX 5.2 with perl 5.8.2,
mod_perl 1.29 and apache 1.3.29. The error (pasted below) puzzles me ;
any clues ?
$ make
cp SubProcess.pm blib/lib/Apache/SubProcess.pm
/opt/hexaflux/perl/bin/perl -e 'use ExtUtils::Mksymlists; Mksymlists(NAME
=
Stas Bekman wrote:
Again, this information could be wrong if you have more than one build of
mod_perl under the same perl tree. Consider: you build and install mod_perl.so
against a threaded httpd and then you build and install another one against a
non-threaded httpd. Apache::Build will
Stas Bekman wrote:
The perl shipped with RH 9 (actually a 5.8.0 + lots of patches)
is compiled with threads and with a shared libperl.so, two factors that
are known to slow things down. I think that 5.8.0 is slower than 5.6.x,
but not considerably. However I have no definitive numbers
Perrin Harkins wrote:
On Mon, 2003-11-03 at 12:12, Todd White wrote:
this system also has Perl version 5.8.1 installed. is there any way to
use the 5.8.1 interpreter without rebuilding mod_perl?
No, there isn't. Frankly, unless you really need something that is in
5.8.1 you should
Perrin Harkins wrote:
I've been running benchmarks of various IPC modules, like MLDBM::Sync,
DBD::MySQL, etc. A version of 5.6.1 with all defaults taken runs them
about 50% faster than the version of 5.8 that shipped with Red Hat 9.
Granted, I heard that 5.8.1 made some gains in dealing with
Jeff Boes wrote:
And here's what perl -V produces from the command line (is there a way
to do an equivalent thing from within a mod_perl script?):
use Config qw/myconfig/;
print myconfig;
13 matches
Mail list logo
