Stas Bekman wrote:
> Another fix from Terrence. That site is indeed down.
>
> Original Message
> Subject: mod_perl 2.0 user guide suggestions
> Date: Sat, 3 Dec 2005 13:53:10 -0800
> From: Terrence Brannon <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
Another fix from Terrence. That site is indeed down.
Original Message
Subject: mod_perl 2.0 user guide suggestions
Date: Sat, 3 Dec 2005 13:53:10 -0800
From: Terrence Brannon <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi, you make reference to perldoc.com i
Done.
Lincoln
On Thursday 14 April 2005 09:49 am, Geoffrey Young wrote:
> Lincoln Stein wrote:
> > No, I'm ready to release the new version whenever it's convenient for
> > you.
>
> ok, I just released RC5 to CPAN, so whenever you have time to release
> 3.08 would be great.
>
> thanks for your he
Lincoln Stein wrote:
> No, I'm ready to release the new version whenever it's convenient for
> you.
ok, I just released RC5 to CPAN, so whenever you have time to release 3.08
would be great.
thanks for your help with this :)
--Geoff
---
hi all :)
I've updated all of my mod_perl 2.0 CPAN modules so that they work with the
latest mod_perl 2.0 release (RC5 aka 1.999_22) and Apache-Test 1.22. here
is a list if you want to look at them:
Apache-AuthenHook-2.00_04
Apache-Clean-2.00_6
Apache-IncludeHook-2.00_05
A
On Tue, 12 Apr 2005, Steve Hay wrote:
> Geoffrey Young wrote:
>
> >the mod_perl development team is pleased to announce that we have a new
> >candidate for mod_perl 2.0, ready and waiting for testers.
> >
> No good for me on Win32 :(
>
> Using Apache 2.0.5
Steve Hay wrote:
Geoffrey Young wrote:
the mod_perl development team is pleased to announce that we have a new
candidate for mod_perl 2.0, ready and waiting for testers.
No good for me on Win32 :(
Using Apache 2.0.53, bleadperl (@22511), I have the testsuite crashing
the Apache.exe server every
Geoffrey Young wrote:
>the mod_perl development team is pleased to announce that we have a new
>candidate for mod_perl 2.0, ready and waiting for testers.
>
No good for me on Win32 :(
Using Apache 2.0.53, bleadperl (@22511), I have the testsuite crashing
the Apache.exe server every tim
Geoffrey Young wrote:
the mod_perl development team is pleased to announce that we have a new
candidate for mod_perl 2.0, ready and waiting for testers.
[...]
Looks like things are borked on OS X ;-(
Darwin (OS X):
Static: bus error on startup (will investigate)
Dynamic:
worker & pre
Geoffrey Young wrote:
the mod_perl development team is pleased to announce that we have a new
candidate for mod_perl 2.0, ready and waiting for testers.
FBSD 6-current
bleed perl w/out ithreads
http2/prefork apr is not threaded
modules/proxy.t fails for me
error log and test output attached
Stas Bekman wrote:
Adam Prime x443 wrote:
Assuming i was upgrading a machine running RC4 to RC5, what is the
easiest way to remove RC4 so RC5 will install?
make uninstall in the old build directory says it's depreciated
(looking at the makefile), but offers no automated alternative? Will
it do the
Adam Prime x443 wrote:
Assuming i was upgrading a machine running RC4 to RC5, what is the
easiest way to remove RC4 so RC5 will install?
make uninstall in the old build directory says it's depreciated
(looking at the makefile), but offers no automated alternative? Will
it do the job or do I really
the mod_perl development team is pleased to announce that we have a new
candidate for mod_perl 2.0, ready and waiting for testers.
this release, mod_perl 1.999_22, is a _very_ significant release as it
contains major API changes and is completely incompatible with any prior
release of mod_perl
Your patches went into my CVS version, and I think you can say that
for sure the changes will be in CGI.pm version 3.07.
FBSD -current/i386
bleedperl w/ ithreads
turnks of httpd/apr/apr-util/apr-iconv threads
applied CGI.pm patches for 3.08
this is worker + ithreads
only modules/proxy.t fails
Philip M. Gollucci wrote:
Your patches went into my CVS version, and I think you can say that
for sure the changes will be in CGI.pm version 3.07.
FBSD -current/i386
bleedperl w/ ithreads
turnks of httpd/apr/apr-util/apr-iconv threads
applied CGI.pm patches for 3.08
this is prefork + ithreads
o
Your patches went into my CVS version, and I think you can say that
for sure the changes will be in CGI.pm version 3.07.
FBSD -current/i386
bleedperl w/out ithreads
turnks of httpd/apr/apr-util/apr-iconv no threads
applied CGI.pm patches for 3.08
minus the apache_content_length header test as po
Geoffrey Young wrote:
Lincoln Stein wrote:
Hi Geoffrey,
Your patches went into my CVS version, and I think you can say that
for sure the changes will be in CGI.pm version 3.07.
Lincoln, you must have meant 3.08. As 3.07 is already out there ;)
--
_
Lincoln Stein wrote:
> Hi Geoffrey,
>
> Your patches went into my CVS version, and I think you can say that
> for sure the changes will be in CGI.pm version 3.07.
great!
> I'd like to
> coordinate our releases so that it will encourage both mod_perl 2.0
> users
hi Lincoln.
the attached patch updates the CGI.pm distribution to work with the new
mod_perl 2.0 API.
because of the massive API changes that have occured recently, it is a
forward only update - older versions of mod_perl 2.0 (from the start of the
project up to the current CPAN release) are not
Joe Schaefer wrote:
> Geoffrey Young <[EMAIL PROTECTED]> writes:
>
> [...]
>
>
>>I really don't see how it can be any other way - I absolutely,
>>positively do not want to deal with questions about how prior beta
>>versions mix with later beta versions and, eventually, the official
>>2.0.
>
>
Geoffrey Young <[EMAIL PROTECTED]> writes:
[...]
> I really don't see how it can be any other way - I absolutely,
> positively do not want to deal with questions about how prior beta
> versions mix with later beta versions and, eventually, the official
> 2.0.
So then, the proposed branch is a re
On Sun, 20 Mar 2005, Geoffrey Young wrote:
> To take a look at the codebase you can checkout the following branch
> from subversion:
>
> http://svn.apache.org/repos/asf/perl/modperl/branches/apache2-rename-unstable
>
> and test and install it as usual.
For those Win32 users wishing to give this a
>
> make dist has a problem, so I can't roll a tarball at the moment.
try this
http://cvs.apache.org/~geoff/mod_perl-unstable.tar.gz
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAI
Geoffrey Young <[EMAIL PROTECTED]> writes:
> I would expect that, barring any new developments,
> we should be able to roll a candidate by monday
> at the latest.
-1, let's not rush things. We're not all on the same
page right now, even as developers, so there needs
to be some/lots of formal v
branch.
>
>
> I have to say I'm yet to take a detailed look at this branch, but then
> my svn kung fu is fairly weak.
$ svn checkout "http://..."; mod_perl-2.0-rename
>
> Is there a one liner for producing a snap-shot tarball so I can take a
> look throu
> "Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes:
Geoffrey> - first, assume lazy consensus if nobody hollers with something new
that
Geoffrey> we haven't already heard and discussed ad nauseum
Mark me as a lazy consenter. :-)
--
Randal L. Schwartz - Stonehenge Consulting Service
Adam Kennedy wrote:
>> no, the mp2 MakeMaker tools serve many purposes, and installing into
>> Apache2
>> is just one of them. another is, for instance, letting XS modules know
>> where the mod_perl header files and typemaps are, or (IIRC) adding things
>> that, say, win32 needs to know about.
>
no, the mp2 MakeMaker tools serve many purposes, and installing into Apache2
is just one of them. another is, for instance, letting XS modules know
where the mod_perl header files and typemaps are, or (IIRC) adding things
that, say, win32 needs to know about.
so no, they stay. but now pure perl m
Adam Kennedy wrote:
>> yes, it would suck, but I don't see how it would cause new problems.
>> Apache2:: is a namespace like any other, and it previously did not
>> exist, so
>> I would expect it to install like any other namespace but not stomp on
>> prior
>> existing stuff, which were the big c
yes, it would suck, but I don't see how it would cause new problems.
Apache2:: is a namespace like any other, and it previously did not exist, so
I would expect it to install like any other namespace but not stomp on prior
existing stuff, which were the big concerns.
Indeed. And the other half of t
Joe Schaefer wrote:
> Geoffrey Young <[EMAIL PROTECTED]> writes:
>
> [...]
>
>
>> - you cannot make, test, or install the unstable branch over any
>>other version of mod_perl-1.99
>
>
> Blech. IMO that's a rather serious problem with this branch.
> Any thoughts on how it could be fixed
Anybody know if this branch actually solves our current CPAN
issues with trunk? It'd royally suck if we just displaced
the known CPAN/installer problems with trunk with a whole new
set of CPAN/installer problems associated with this branch.
I have to say I'm yet to take a detailed look at this
Joe Schaefer wrote:
> Geoffrey Young <[EMAIL PROTECTED]> writes:
>
> [...]
>
>
>> - mod_perl.pm is now mod_perl2.pm
>>
>> - Apache2.pm no longer exists
>
>
> Procedural question: how should we vote on
> this stuff? At this point, I think we should
> treat this proposal as just that, a p
Geoffrey Young <[EMAIL PROTECTED]> writes:
[...]
>
> - mod_perl.pm is now mod_perl2.pm
>
> - Apache2.pm no longer exists
Procedural question: how should we vote on
this stuff? At this point, I think we should
treat this proposal as just that, a proposal.
Any ideas about how, and when, we
Geoffrey Young <[EMAIL PROTECTED]> writes:
[...]
> - you cannot make, test, or install the unstable branch over any
> other version of mod_perl-1.99
Blech. IMO that's a rather serious problem with this branch.
Any thoughts on how it could be fixed?
[...]
> If you have issues or concerns
Tom Schindl <[EMAIL PROTECTED]> writes:
> What's going to happen to Apache::Request will it also follow this
> direction and renamed Apache2::Request?
TBD- I think that issue depends on what folks say about the
current renaming proposal for mp2. In the past the apreq-dev
has always honored the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
my svn-client refuses to checkout from the repository telling me that
the URL-Schema is unknown. Are there any tar.gz's to download or even
better does anybody know what that means(does my distribution forgot to
add this protocol). I'm using Mandrak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What's going to happen to Apache::Request will it also follow this
direction and renamed Apache2::Request?
Tom
Joe Schaefer wrote:
| Geoffrey Young <[EMAIL PROTECTED]> writes:
|
| [...]
|
|
|>The process has reached the point where discussion ought to m
Geoffrey Young <[EMAIL PROTECTED]> writes:
[...]
> The process has reached the point where discussion ought to move back
> into the general community - the majority in the PMC have a proposed
Apologies- late correction: it's more accurate to say "a co
As you all well know, the mod_perl 2.0 release process encountered
a substantial obstacle in late December concerning our choice of
namespaces for the 2.0 API. In January[1] the mod_perl PMC
promised to examine the concerns that had been raised on all sides,
the needs of our userbase, the
Stas Bekman said:
> The thing is: 99.9% of users need to have only one modperl generation,
> therefore I think the conflicting marking is the preferrable approach. But
> I could be wrong.
I'm not sure they actually mark them as conflicting, but they do seem to
be coping with this so far, since Red
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> =item * Distributors
>
> Distributors should mark the different generations of mod_perl as
> conflicting, so only one version can be installed using the binary
> package. Users requiring more than one installation should do a manual
> install.
+1
Adam Kennedy wrote:
=item * Distributors
Distributors should mark the different generations of mod_perl as
conflicting, so only one version can be installed using the binary
package. Users requiring more than one installation should do a manual
install.
>>> So I presume this would apply to all of A
Stas Bekman wrote:
Mind to post this to the list? It's an important issue, that was just an
idea I wrote last night.
Adam Kennedy wrote:
(off-list)
So I presume this would apply to all of Apache-related CPAN modules as
well?
Wouldn't this mean that people like debian are going to have
libapache
Perrin Harkins wrote:
Adam Kennedy said:
While I'm thinking about it, has anyone talked to Red Hat or the Debian
people to see how the separate distribution of identically named module
will work within all of the distro's various packaging systems?
Doesn't seem like a problem to me since a) they j
Perrin Harkins wrote:
Adam Kennedy said:
While I'm thinking about it, has anyone talked to Red Hat or the Debian
people to see how the separate distribution of identically named module
will work within all of the distro's various packaging systems?
Doesn't seem like a problem to me since a) they
Adam Kennedy wrote:
If a module has XS code and doesn't provide a CLONE function, most
likely it is not thread-safe (you can grep for CLONE). Of course those
that provide the CLONE function aren't necessarily completely
thread-safe. e.g. I've added CLONE only for the top level class in
GTop, th
Adam Kennedy said:
> While I'm thinking about it, has anyone talked to Red Hat or the Debian
> people to see how the separate distribution of identically named module
> will work within all of the distro's various packaging systems?
Doesn't seem like a problem to me since a) they just ship the mod
If a module has XS code and doesn't provide a CLONE function, most
likely it is not thread-safe (you can grep for CLONE). Of course those
that provide the CLONE function aren't necessarily completely
thread-safe. e.g. I've added CLONE only for the top level class in GTop,
the rest of classes in
Perrin Harkins wrote:
Adam Kennedy said:
I'm wondering how you plan to make the modifications to the various
modules that might be effected by this new concept of "two different
modules (APIs) with the same name"
Adam, this is under heavy discussion right now and is not really resolved.
There is
thing. I'm not aware
of any automatic scanning utility for this.
> There are 14 million lines of perl in CPAN, are we going to have to
> rewrite all of them to make them thread-safe before we can use any of
> them with mod_perl 2.0?
If you want to run them with threads, then yes, th
them to make them thread-safe before we can use any of
them with mod_perl 2.0? We have enough problems maintaining some of them
already...
I would imagine that many modules can't be made thread-safe without
fundamentally changing their APIs as well... do you see a risk of API
cascade here,
Stas Bekman wrote:
gSOAP acct wrote:
Hi Stas,
I think I got the cvs version of modperl you mentioned
...
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic
co modperl-2.0
... Is that right?
Right.
> modperl_constants.c:1576: error: `AP_MPMQ_RUNNING'
> undeclared (first use in this function)
I
Stas Bekman wrote:
gSOAP acct wrote:
Hi Stas,
I think I got the cvs version of modperl you mentioned
...
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic
co modperl-2.0
... Is that right?
Right.
> modperl_constants.c:1576: error: `AP_MPMQ_RUNNING'
> undeclared (first use in this function)
I
gSOAP acct wrote:
Hi Stas,
I just decided to upgade things ...
[...]
... everthing seem to compile and install correctly.
Good for you :) Bad for others, as now we don't know what was the problem and
the we will have to go through the same thing again with the next person
encountering that exact
ignore my last email. Geez I am stupid sometimes.
--- gSOAP acct <[EMAIL PROTECTED]> wrote:
> Hi Stas,
>
> I just decided to upgade things ...
>
> so I did this ...
>
> cvs -d
> :pserver:[EMAIL PROTECTED]:/home/cvspublic
> login
> cvs -d
> :pserver:[EMAIL PROTECTED]:/home/cvspublic
> co modper
Hi Stas,
I just decided to upgade things ...
so I did this ...
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic
login
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic
co modperl-2.0
#To get the cutting edge Apache 2.0 and APR 0.9
projects:
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic
co -
gSOAP acct wrote:
Hi Stas,
Well that got me a lot closer but make test still
failed. Should I upgrade my Apache and try again with
modperl 2.0?
Not really. It should work fine with 2.0.48.
t/apache/subprocess.t 255 65280?? ?? %
??
t/apr/perlio.t 255 65280?? ?? %
Hi Stas,
Well that got me a lot closer but make test still
failed. Should I upgrade my Apache and try again with
modperl 2.0?
$ make test
...
t/preconnection/noteok
t/protocol/echo.ok
gSOAP acct wrote:
Hi Stas,
I think I got the cvs version of modperl you mentioned
...
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic
co modperl-2.0
... Is that right?
Right.
> modperl_constants.c:1576: error: `AP_MPMQ_RUNNING'
> undeclared (first use in this function)
I know what the problem i
Hi Stas,
I think I got the cvs version of modperl you mentioned
...
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic
co modperl-2.0
... Is that right?
Next I do this ...
perl Makefile.PL MP_APXS=/usr/local/apache2/bin/apxs
... and now when I do my make I get this ...
cc -I/home/Plankton/cvs
[remember to reply back to the list! Thanks]
gSOAP acct wrote:
I forgot about having mod_perl and perl built with the
same compiler. I'll rebuild perl and if that doesn't
work I'll get the current modperl cvs and try again as
you suggest.
I think you *need* to use modperl cvs. If I were you I'd d
gSOAP acct wrote:
-8<-- Start Bug Report
8<--
1. Problem Description:
I get a lot of test failures when I run make test.
but you showed us the failure of the first one. I guess a lot more fail, right?
Please get the current modperl cvs and try again. Most l
-8<-- Start Bug Report
8<--
1. Problem Description:
I get a lot of test failures when I run make test.
Here's the output from the make test ...
linux:/home/Plankton/mod_perl/mod_perl-1.99_13 # rm
t/logs/error_log
linux:/home/Plankton/mod_p
Geoffrey Young wrote:
hi all
we're about to enter into another release cycle for mod_perl 2.0, so I'd
like to ask for a code freeze until the release candidate has been
rolled, then allow only fixes to reported RC problems until 1.99_11 is
official.
1.99_11-RC1 should be on it
hi all
we're about to enter into another release cycle for mod_perl 2.0, so I'd
like to ask for a code freeze until the release candidate has been rolled,
then allow only fixes to reported RC problems until 1.99_11 is official.
1.99_11-RC1 should be on it's way sh
Stas Bekman wrote:
As I was exposing mpxs_Apache_request as I needed it in Apache::Peek, I
was thinking what is the public C mod_perl API. Is that everything that
is defined in mod_?perl.*\.h and modperl_xs.*\.h files? What about the
XS extensions, if a 3rd party app wants to use a C function
As I was exposing mpxs_Apache_request as I needed it in Apache::Peek, I was
thinking what is the public C mod_perl API. Is that everything that is defined
in mod_?perl.*\.h and modperl_xs.*\.h files? What about the XS extensions, if
a 3rd party app wants to use a C function which is not in the c
hi all...
I had a few moments so I've started to port Apache::Clean over to
mod_perl 2.0. it's far from complete, and I haven't examined all the
issues with proper caching headers yet, but you can find the work in
progress here:
http://www.modperlcookbook.org/~geoff/modul
Jeff Stuart wrote:
> Question? What is the status of mod_perl 2.0? Also, is it working
> with/playing with Apache 2.0 at all?
Tell me what's the status of apache 2.0 and I'll tell you the status of
mod_perl 2.0 :)
But seriously mod_perl 2.0 will be ready about the time
Question? What is the status of mod_perl 2.0? Also, is it working
with/playing with Apache 2.0 at all?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Fri, 4 Jan 2002, Stas Bekman wrote:
> > but yes, registry scripts would need some sort of protection as well.
>
> I cannot see where registry scripts differ from handlers, from the
> access to internals point of view. Once you run under mod_perl it
> doesn't matter what you do. You've to ha
On Sun, 6 Jan 2002, Sebastian Bergmann wrote:
> Randy Kobes wrote:
> > Great ... If you're trying next 'nmake test', you may find
>
> Haven't tried 'nmake test' yet, but: Apache.exe crashes on shutdown
> when mod_perl is loaded.
Yes, that happened before with an earlier modperl-1.3?; it was
On Sun, 6 Jan 2002, Sebastian Bergmann wrote:
> I can't build a debug version of mod_perl by setting MP_DEBUG=1 when I
> run Makefile.pl, the compiler barks out with unknown compiler flags. So,
> no stacktrace.
i have perl on win32 built with debugging, so modperl inherits the debug
flags
Randy Kobes wrote:
> Great ... If you're trying next 'nmake test', you may find
Haven't tried 'nmake test' yet, but: Apache.exe crashes on shutdown
when mod_perl is loaded.
Reminds me: What changes do I have to make to httpd.conf, besides the
obvious
LoadModule perl_module modules/l
On Sat, 5 Jan 2002, Sebastian Bergmann wrote:
> Thanks for your help, it builds fine now.
Great ... If you're trying next 'nmake test', you may find
some problems with not being able to find certain modules
in @INC. This is because, due to case-insensitive filenames
on Win32, perl copying a 'L
Randy Kobes wrote:
> Ah ... That's probably the problem - modperl is looking for
> certain header files in the MP_AP_PREFIX parent directory,
> and if they're not found, the error you got would result.
Thanks for your help, it builds fine now.
--
Sebastian Bergmann
http://sebastian-bergma
On Sat, 5 Jan 2002, Sebastian Bergmann wrote:
> Randy Kobes wrote:
> > No, it shouldn't be - the install to \server\apache should also
> > copy the needed include and lib files. And there's no spaces in
> > the names, so it's not croaking on that ... If it doesn't make
> > any difference to you,
On Sat, 5 Jan 2002, Stas Bekman wrote:
> I thought his question was abouthow to make INC private
> to various vh's. The answer is that it's done.
>
> Have I misinterpreter the question? Or are we talking
> about different things?
ah, i must have misread the last message.
of course, there is sti
Jay Lawrence wrote:
> Stas,
>
> Thank you for the link. I was not aware of this document. The PerlOptions
> directive looks like an excellent design decision!
Thank Doug for designing/implementing, not me for sending a link :)
--
_
y Young" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, January 04, 2002 9:25 PM
Subject: Re: mod_perl 2.0 for ISPs
> Jay Lawrence wrote:
>
> > Another point that was mentioned by someone in my local Mongers group
> > was that of different INC paths for differ
brian moseley wrote:
> On Sat, 5 Jan 2002, Stas Bekman wrote:
>
>
>>Guys, I suggest that you read the design docs before you
>>continue. The INC issue has been addressed already.
>>Please read:
>>http://apache.org/~dougm/modperl_2.0.html
>>http://apache.org/~dougm/modperl_design.html
>>
>
> th
Sebastian Bergmann wrote:
> C:\home\apache\modperl-2.0>perl makefile.pl MP_USE_DSO=1
> MP_GENERATE_XS=1 MP_AP_PREFIX=c:\server\apache
Just noticed that MP_AP_PREFIX should point to the binary directly on
*NIX, so I tried
perl makefile.pl MP_USE_DSO=1 MP_GENERATE_XS=1
MP_AP_PREFIX=c:
Randy Kobes wrote:
> No, it shouldn't be - the install to \server\apache should also
> copy the needed include and lib files. And there's no spaces in
> the names, so it's not croaking on that ... If it doesn't make
> any difference to you, what happens if you install to C:\Apache2?
> That works f
On Sat, 5 Jan 2002, Stas Bekman wrote:
> Guys, I suggest that you read the design docs before you
> continue. The INC issue has been addressed already.
> Please read:
> http://apache.org/~dougm/modperl_2.0.html
> http://apache.org/~dougm/modperl_design.html
that may not be exactly what he's wish
Jay Lawrence wrote:
> Another point that was mentioned by someone in my local Mongers group
> was that of different INC paths for different sets of users. I confess not
> to
> have given this much thought but upon initial thinking it seems that if
> different users want to have isolated local mod
On Fri, 4 Jan 2002, Sebastian Bergmann wrote:
> Randy Kobes wrote:
> > Is this a binary install of Apache2, or one that you compiled
> > yourself from the httpd-2.0 cvs sources?
>
> I always build from the sources myself. The sources, however are
> located in c:\home\apache\httpd-2.0, not in
Another point that was mentioned by someone in my local Mongers group
was that of different INC paths for different sets of users. I confess not
to
have given this much thought but upon initial thinking it seems that if
different users want to have isolated local modules (differing versions
of the
Randy Kobes wrote:
> Is this a binary install of Apache2, or one that you compiled
> yourself from the httpd-2.0 cvs sources?
I always build from the sources myself. The sources, however are
located in c:\home\apache\httpd-2.0, not in c:\server\apache\. Is this
a problem?
--
Sebastian B
On Fri, 4 Jan 2002, Sebastian Bergmann wrote:
> Randy Kobes wrote:
> > Is C:\server\apache the directory to which Apache2 was installed?
>
> Yes, and C:\Server\Apache\bin\Apache.exe is the executable.
Is this a binary install of Apache2, or one that you compiled
yourself from the httpd-2.0 cvs
Randy Kobes wrote:
> Is C:\server\apache the directory to which Apache2 was installed?
Yes, and C:\Server\Apache\bin\Apache.exe is the executable.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishl
On Fri, 4 Jan 2002, Sebastian Bergmann wrote:
> What am I doing wrong, now?
>
> C:\home\apache\modperl-2.0>perl makefile.pl MP_USE_DSO=1 MP_GENERATE_XS=1
> MP_AP_PREFIX=c:\server\apache
> Reading Makefile.PL args from @ARGV
>MP_USE_DSO = 1
>MP_GENERATE_XS = 1
>MP_AP_PREFIX = c:\serv
What am I doing wrong, now?
C:\home\apache\modperl-2.0>perl makefile.pl MP_USE_DSO=1 MP_GENERATE_XS=1
MP_AP_PREFIX=c:\server\apache
Reading Makefile.PL args from @ARGV
MP_USE_DSO = 1
MP_GENERATE_XS = 1
MP_AP_PREFIX = c:\server\apache
readline() on closed filehandle Apache::Build::$fh at
What am I doing wrong, now?
C:\home\apache\modperl-2.0>perl makefile.pl MP_USE_DSO=1 MP_GENERATE_XS=1
MP_AP_PREFIX=c:\server\apache
Reading Makefile.PL args from @ARGV
MP_USE_DSO = 1
MP_GENERATE_XS = 1
MP_AP_PREFIX = c:\server\apache
readline() on closed filehandle Apache::Build::$fh a
Stas Bekman wrote:
>
> >>I think the first thing to lookat is how PHP builds the jail.
> >>
> >
> > two different issues, no? one is about normal cgi/registry scripts
> > and the other about accessing areas of the server through the API.
> >
> > but yes, registry scripts would need some sort of
>>I think the first thing to lookat is how PHP builds the jail.
>>
>
> two different issues, no? one is about normal cgi/registry scripts
> and the other about accessing areas of the server through the API.
>
> but yes, registry scripts would need some sort of protection as well.
I cannot see
Stas Bekman wrote:
>
> Geoffrey Young wrote:
>
> > hi all...
> >
> > I was wondering if any thought was given to designing mod_perl 2.0
> > with ISPs in mind. I know this issue has cropped up on modperl@ but
> > I've been thinking about
Geoffrey Young wrote:
> hi all...
>
> I was wondering if any thought was given to designing mod_perl 2.0
> with ISPs in mind. I know this issue has cropped up on modperl@ but
> I've been thinking about it lots lately and have an idea (well, some
> ramblings, anyway)...
Yeah I also think that 'cause we lack such a support beat mod-Perl so
much !! In the time it is much more powerfull than PHP or so, lacking
support for mass-hosting doesn't give a chance for mod_perl to make it
most widly used..
my 5c
[EMAIL PROTECTED]
-
hi all...
I was wondering if any thought was given to designing mod_perl 2.0
with ISPs in mind. I know this issue has cropped up on modperl@ but
I've been thinking about it lots lately and have an idea (well, some
ramblings, anyway)...
there are lots of problems with allowing users to
1 - 100 of 142 matches
Mail list logo
