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;
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 sho
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 w
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 numbe
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
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"
=> "Apa
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))
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
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
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
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
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
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 yo
14 matches
Mail list logo
