Geoffrey Young wrote:
Ryan Underwood wrote:
Hi,
I'm looking for a solution to the following problem.
I have an engine library MySite which is a common base of code used to
build a new site upon.
Site1, Site2, and Site3 each have a copy of MySite at various stages in
development; the copies of MySit
Ryan Underwood wrote:
> Hi,
>
> I'm looking for a solution to the following problem.
>
> I have an engine library MySite which is a common base of code used to
> build a new site upon.
>
> Site1, Site2, and Site3 each have a copy of MySite at various stages in
> development; the copies of MySi
Hi,
I'm looking for a solution to the following problem.
I have an engine library MySite which is a common base of code used to
build a new site upon.
Site1, Site2, and Site3 each have a copy of MySite at various stages in
development; the copies of MySite aren't always in a consistent state
be
Greg Matheson wrote:
In the 1.0 documentation there is a section on ways to confirm
the version of mod_perl being run: checking the error_log,
viewing /perl-status, telnetting in and getting the environmental
variables with a script.
However, I can't find any corresponding section in the 2.0 docume
In the 1.0 documentation there is a section on ways to confirm
the version of mod_perl being run: checking the error_log,
viewing /perl-status, telnetting in and getting the environmental
variables with a script.
However, I can't find any corresponding section in the 2.0 documentation.
So, the fa
>> i am registering the handler like so:
>> $r->register_cleanup('MyPackage::LongProcess');
>
>
> what's MyPackage::LongProcess, a package name or a subroutine? It should
> be a subroutine.
actually, while it looks like 2.0 supports a few different forms, I think it
can only be a reference to a
On Saturday, October 2, 2004, at 12:57 PM, Charlie Garrison wrote:
The only one I can see which looks like a possible offender is
HTML::Template. The $args{print_to} is previously set to *STDOUT. If I
get a chance I'll setup a test config which doesn't use HTML::Template
and see of the problem goe
Good morning,
On 2/10/04 at 10:46 AM -0400, Stas Bekman <[EMAIL PROTECTED]> wrote:
>> This is a common problem with mod_perl and OSX. Add the following to your
>> httpd.conf file:
>>
>> # fix for mod_perl print()
>> PerlHeaderParserHandler "sub { tie *STDOUT, 'Apache' unless tied *STDOUT; }"
>>
On Saturday, October 2, 2004, at 09:49 AM, Charlie Garrison wrote:
Good evening,
On 1/10/04 at 9:13 PM -0400, Sam Wilkins <[EMAIL PROTECTED]>
wrote:
No matter what I run, even that, I get document contains no data. It
works from the command line. If it helps, I'm on Mac OS X 10.3.5,
Apache 1.3.2
Sean, to start with always read http://perl.apache.org/bugs/ before
sending a bug/problem report. I can't tell from your report what modperl
generation/version you are using.
Sean Scanlon wrote:
I am having a problem with using a cleanup handler where it seems that
the CleanupHandler is blocking
Charlie Garrison wrote:
Good evening,
On 1/10/04 at 9:13 PM -0400, Sam Wilkins <[EMAIL PROTECTED]> wrote:
No matter what I run, even that, I get document contains no data. It
works from the command line. If it helps, I'm on Mac OS X 10.3.5,
Apache 1.3.29, and I don't know how to determine my mod
Good evening,
On 1/10/04 at 9:13 PM -0400, Sam Wilkins <[EMAIL PROTECTED]> wrote:
>No matter what I run, even that, I get document contains no data. It
>works from the command line. If it helps, I'm on Mac OS X 10.3.5,
>Apache 1.3.29, and I don't know how to determine my mod_perl version.
This
I apologize if this has been posted here before, but I don't recall
seeing it.
The ActiveState guys recently posted that they are stopping all
development (although support will continue through March 2005) on PerlEx.
http://www.activestate.com/Products/PerlEx/
For those that are not aware, Per
13 matches
Mail list logo
