On Thu, Dec 30, 2004 at 05:57:07PM -0500, Stas Bekman wrote:
During compilation of mod_perl, I was seeing undefined reference errors
which are nicely described on the install page[1]. The prescription
suggests rebuilding Perl with dynamic linking; apparently the version
that's shipped with
Joshua Hoblitt wrote:
On Mon, Dec 27, 2004 at 12:10:47PM -0500, Perrin Harkins wrote:
The real significant issue to address, IMO, has to do with CPAN's
indexing of the Apache:: modules common to both mp1 and mp2 core
distros, because those packages set the underlying apache[12]
architecture.
I know what's happening now, it dawned on me after I wrote this last night.
A deadlock happens when you have an updater that acquires a write
lock, but it's waiting for the first updater that is also in a SELECT
FOR UPDATE but has not yet acquired a write lock. The first updater
can't finish
Joe Schaefer wrote:
Stas Bekman [EMAIL PROTECTED] writes:
Joe Schaefer wrote:
[...]
Looks very promising to me. Is there a way to tell PAUSE to index
mod_perl's Apache::* modules from a bundle? If so, that might
provide a decent solution for both mod_perl and libapreq
(and other Apache::*
On Fri, 31 Dec 2004, Stas Bekman wrote:
Octavian Rasnita wrote:
Hi,
I want to configure a production server that uses
mod_perl and I don't know what version to choose because
I see that mod_perl 2 is not stable yet. What do you
recommend, to install Apache 1.3 and mod_perl 1 and use
William McKee wrote:
Thanks for the clear explanation of *.a and *.so files, Stas. I'm
starting to grok how it works together.
I've attached the diff to the install docs to this message which
incorporates some of your notes about .so and .a files. I found this
information hard to find while
Joe Schaefer wrote:
Stas Bekman [EMAIL PROTECTED] writes:
Randy Kobes wrote:
[...]
There's still mod_perl.pm in both packages, though. In mp2,
this is just something to define the version, and also to
provide a NAME pod section (if I remember correctly, this
was inserted for the benefit of
William McKee wrote:
On Fri, Dec 31, 2004 at 02:02:59PM -0500, Stas Bekman wrote:
Thanks William, I've committed that with a few tweaks. Especially the last
para. Please check that it still makes sense.
Looks fine except for a couple of typos (dangling quote mark and
mispelled 'should'). Also,
I'm going to chime in, as someone working on a suite of modules that are
intended to eventually work with apache 1.x and 2.x. First, I agree with
this:
On 12/31/04 2:27 PM, Adam Kennedy wrote:
For the moment, I'm asking just that the release of mod_perl 2.0 be put
on hold until this problem,
Stas == Stas Bekman [EMAIL PROTECTED] writes:
Stas 99.9% of users do *not* need to use this workaround. So that
Stas issue is moot if you ask me.
You keep saying this like you believe it. In fact, the number keeps
getting closer to 100% each time.
This is pure, fabricated *fiction*.
Four out
John Siracusa wrote:
On 12/31/04 4:40 PM, Stas Bekman wrote:
Finally you don't want to use it - don't use it. It's an open source
software, it will succeed or fail by *its own merits* and not because the
infrastructure has a long known problem but is not willing to evolve.
And to repeat this
Randal L. Schwartz wrote:
Four out of my five biggest customers *will* need to have both
modperl1 and modperl2 in the same Perl installation tree on their
Bullcrap - I would say that sep perl installs is not enough!
Personally I would hate to work for anyone who does insists
on dev/testing on live
Stas 99.9% of users do *not* need to use this workaround. So that
Stas issue is moot if you ask me.
Randal You keep saying this like you believe it. In fact, the number
keeps
Randal getting closer to 100% each time.
Randal This is pure, fabricated *fiction*.
For me, this ends up being the sane
Author: stas
Date: Fri Dec 31 15:02:49 2004
New Revision: 123829
URL: http://svn.apache.org/viewcvs?view=revrev=123829
Log:
polish test
Modified:
perl/modperl/trunk/t/lib/TestAPRlib/bucket.pm
Modified: perl/modperl/trunk/t/lib/TestAPRlib/bucket.pm
Url:
Author: stas
Date: Fri Dec 31 15:13:48 2004
New Revision: 123830
URL: http://svn.apache.org/viewcvs?view=revrev=123830
Log:
clarify the usage of the confusing apr API, the returned bucket pointer is
the same as the first argument, which is modified by reference.
Modified:
Author: stas
Date: Fri Dec 31 15:40:23 2004
New Revision: 123832
URL: http://svn.apache.org/viewcvs?view=revrev=123832
Log:
no need for a special handling of out-of-scope pools for $b-setaside($p)
as it's already handled internally by APR
Modified:
Author: stas
Date: Fri Dec 31 16:25:13 2004
New Revision: 123834
URL: http://svn.apache.org/viewcvs?view=revrev=123834
Log:
APR::BucketAlloc: new now holds onto the pool object and doesn't release
it until it itself is destroyed
Modified:
perl/modperl/trunk/Changes
17 matches
Mail list logo
