Re: ??: ??: Class inheritance, and SUPER under mod_perl2
Joe Schaefer :
Nguyen Vu Hung [EMAIL PROTECTED] writes:
foreach $h (@{$hosts})
{
$obj = $type-SUPER::new(PeerAddr = ($host = $h),
Are you sure you want SUPER::new()? I think in your
case it translates to Net::Cmd::new(), when your args
suggest you want IO::Socket::INET::new().
It won't work. I don't know the reason but because $obj inherits from 02
classes, not only Net::Cmd::new
PeerPort = 110, #$arg{PeerPort} || 110,#(110)',
Proto = 'tcp',
LocalPort = 110,
You can't bind to LocalPort 110 unless you are root.
Try doing without the LocalPort = 110 argument,
there's probably no need for it.
I finally gave you and pended this issue.
At the moment, I am hardcoding all the parameters, and it works well :D.
BR,
Vu Hung
IPC::Run question
After sending a hardtime with IPC::Run, I still didn't understand it
from usage example, so I post it here.
In the code below, what [EMAIL PROTECTED], $in, $out, $err? How to declare them?
Question 01:
#http://www.annocpan.org/~RSOD/IPC-Run-0.80/lib/IPC/Run.pm
## Using run() instead of system():
use IPC::Run qw( run timeout ) ;
run [EMAIL PROTECTED], \$in, \$out, \$err, timeout( 10 ) or die cat: $?
# Can do I/O to sub refs and filenames, too:
run [EMAIL PROTECTED], '', in.txt, \out, \err or die cat: $?
run [EMAIL PROTECTED], '', in.txt, '', out.txt, '2', err.txt ;
# Redirecting using psuedo-terminals instad of pipes.
run [EMAIL PROTECTED], 'pty', \$in, 'pty', \$out_and_err ;
Question 02:
The following code using IPC::open3 ( works fine under Perl 5.5.6,
mod_perl 1.3, Apache 1.3.x ) to run and command.
How does it look like if I port it to IPC::Run ( under Perl 5.5.8,
mod_perl 2.0.3, Apache 2.0.52 )
# IPC::open3 is no longer available under the new environment.
my $OUT = new FileHandle;
my $IN = new FileHandle;
my $ERR = new FileHandle;
my $tie_stdin = tied *STDIN;
my $tie_stdout = tied *STDOUT;
my $tie_done = undef;
untie *STDIN if $tie_stdin;
untie *STDOUT if $tie_stdout;
my $pid;
#eval { $pid = open3( $OUT, $IN, $ERR, /path/to/cmd $paramx ) };
Re: Using Apache 2.2 from ApacheLounge for Win32 modperl
Actually note that it isn't a release and is being rerolled. Seems Apachelounge is doing themselves and their users a disservice, again. I disagree. ApacheLounge's binary distribution is the only one that (configured with modperl) survives an application restart. As I posted in an earlier mail, ASF's binaries do not work in modperl setups. So far I have not received any response (only verifications) that contradict my findings. I applaud the people who put in effort (AND maintain a web site for that) to fix a long-standing problem, and share it with the professionals at large. It's a lot of work, and it takes a great spirit to think for the rest of us code compiler noobs.
Re: Using Apache 2.2 from ApacheLounge for Win32 modperl
This might be a result of what was mentioned before about possible problems using the binaries from http://www.apachelounge.com/download/ (which is compiled with VC++ 2005) with ActivePerl and ActivePerl-compatible ppm packages (which are compiled with VC++ 6). Mixing these can lead to conflicts, as discussed at, eg, http://search.cpan.org/src/SHAY/Win32-UTCFileTime-1.46/INSTALL You're probably right. The only saving grace is the Apache binaries seem to be nicely decoupled from the modperl/ libapreq2 code. I have not had much issues marrying them together. The only thorn I'm dealing with is that spaces in directory names is not good. But I can live with that.
Re: Using Apache 2.2 from ApacheLounge for Win32 modperl
On Mon, 20 Aug 2007, Foo JH wrote: Actually note that it isn't a release and is being rerolled. Seems Apachelounge is doing themselves and their users a disservice, again. I disagree. ApacheLounge's binary distribution is the only one that (configured with modperl) survives an application restart. As I posted in an earlier mail, ASF's binaries do not work in modperl setups. So far I have not received any response (only verifications) that contradict my findings. I applaud the people who put in effort (AND maintain a web site for that) to fix a long-standing problem, and share it with the professionals at large. It's a lot of work, and it takes a great spirit to think for the rest of us code compiler noobs. There wasn't a quarrel with ApacheLounge providing binary distributions in general, and indeed, this is encouraged in the broad community within the guidelines of the Apache Software Foundation (ASF). The specific issue here was that there was a binary distribution available on the ApacheLounge site (which has since been removed) which wasn't marked very clearly as being built from sources of an ASF release candidate, which are intended for testing only. -- best regards, Randy
Perl 5.8.8.
on http://httpd.apache.org/docs/2.0/install.html the following section can be found: Perl 5 [OPTIONAL] For some of the support scripts like apxs or dbmmanage (which are written in Perl) the Perl 5 interpreter is required (versions 5.003 or newer are sufficient). If you have multiple Perl interpreters (for example, a systemwide install of Perl 4, and your own install of Perl 5), you are advised to use the --with-perl option (see below) to make sure the correct one is used by configure. If no Perl 5 interpreter is found by the configure script, you will not be able to use the affected support scripts. Of course, you will still be able to build and use Apache 2.0. There is however no section below explaining the --with-perl option. I am trying to upgrade perl 5.8.7 to 5.8.8 but apache always takes 5.8.7. everywhere else my system uses perl 5.8.8 Does anyone know how --with-perl option works ? or how to compile apache with perl 5.8.8 if this is not the correct way. Thanks Jon
Re: Perl 5.8.8.
On 8/20/07, JónJósef Bjarnason [EMAIL PROTECTED] wrote: Does anyone know how --with-perl option works ? or how to compile apache with perl 5.8.8 if this is not the correct way. The page you're looking at is not related to mod_perl. It is for configuring the command-line utilities that come with apache. Those are affected by the --with-perl option. If you don't plan to use them, you can totally ignore this. To build mod_perl with a specific perl, just call the Makefile.PL with it: /opt/my/special/perl Makefile.PL - Perrin
Re: Perl 5.8.8.
On 8/20/07, JónJósef Bjarnason [EMAIL PROTECTED] wrote: But it's not mod_perl I am conserned with, that seems to sitt nicely at 5.8.8. its Apache, it looks into the old lib directories ../perl/5.8.7 instead of ../perl5/5.8.8 and I can't find where to change that in Apache. Can you be more specific? What exactly is the program you're trying to run that is finding the wrong perl? - Perrin
Re: Perl 5.8.8.
On 8/20/07, JónJósef Bjarnason [EMAIL PROTECTED] wrote: Apache's @INC Apache doesn't have an @INC because Apache doesn't have perl. It looks like this is mod_perl's @INC. Did you print this out from a script or module running through mod_perl? To change which perl mod_perl is using, you just rebuild it with the right one, as shown in previous mail. - Perrin
