he Win32 binary releases for us.
> Where is apr.h on your machine?
In the single include directory along with ap_*.h header files etc where Apache
was installed into.
Graham
> - Original Message -
> From: "Graham Dumpleton" <[EMAIL PROTECTED]>
> To:
> S
7;libapr-1', 'libaprutil-1', 'ws2_32']
>
> (added the -1 to libapr and libaprutil)
>
> The resultant build produced _psp.pyd and also a mod_python_so.pyd which
> I renamed mod_python.so and it ran.
>
> Does this sound right?
>
> - Jeff
> -
e problem.
Graham
> - Original Message -
> From: "Graham Dumpleton" <[EMAIL PROTECTED]>
> To: "python-dev list"
> Sent: Sunday, November 12, 2006 20:12
> Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32
>
>
> > Jeff Robbins wrote
Graham Dumpleton wrote ..
> That is probably reasonable as late in Apache 2.0.X releases and in Apache
> 2.2.X they changed from version 0.0.9 of Apache runtime library to 1.0.2
> (or
> something like that). Thus, they are probably naming the libraries
> differently.
>
> Loo
Jim Gallacher wrote ..
> Several of your other warnings such as:
>
> C:\work\mod_python-3.3.0-dev-20061109\src\util.c(170) : warning C4244:
> 'function' : conversion from 'double' to 'long', possible loss of data
>
> are the result of converting apr_time_t from microseconds to seconds:
>
>
Jim Gallacher wrote ..
> Graham Dumpleton wrote:
> > Jim Gallacher wrote ..
> >> Several of your other warnings such as:
> >>
> >> C:\work\mod_python-3.3.0-dev-20061109\src\util.c(170) : warning C4244:
> >> 'function' : conversion from
I know that we are very close to getting mod_python 3.3 out the door,
and I know that it is me holding it up purely through the documentation
not yet being updated to at least give some basic details on new bits
in the rewritten module importer, but even at this late stage I have
been
thinking
Jeff Hinrichs - DM&T wrote ..
> On 11/19/06, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> > I know that we are very close to getting mod_python 3.3 out the door,
> > and I know that it is me holding it up purely through the documentation
> > not yet being upda
Don't use MemorySession in the example as it will only work on Windows
and will not work on multi process MPMs on UNIX as each process will
have its own session database instance in its local memory. The
MemorySession
also will not work across Python interpreter instances.
Thus, suggest start
On 03/12/2006, at 7:34 AM, Jim Gallacher wrote:
Eric Brunson wrote:
I apologize if this goes out twice, I think I wrote it on my
laptop at
work, then shut it down without hitting send.
While upgrading to 3.3 on Thursday I ran into the previously
discussed
"pthread_*" unresolved symbol pro
On 03/12/2006, at 1:41 PM, Eric Brunson wrote:
Can you explain properly what that one line is achieving.
The change is causing mod_python to be linked with the same libs that
python was when it was built, in the absence of the Makefile.
If you have the python-dev package installed which doe
Jim, I have updated LaTeX documentation for the apache.import_module()
function. Can you run it through LaTeX and fixup all my wrongly
closed LaTeX
formatting. :-)
Can you and anyone else who is interested, read through the
documentation
I have added and comment on whether it is adequate. Ie
Clodoaldo wrote ..
> 2006/12/3, Graham Dumpleton <[EMAIL PROTECTED]>:
> >
> > Can you and anyone else who is interested, read through the
> > documentation
> > I have added and comment on whether it is adequate. Ie., is there
> > anything
> > th
Sorry, but I am going to take issue with where this session example is headed
as there are number of things being done which I at least would regard as being
bad practice. Please don't take this wrong way, your effort in doing this stuff
in
the first place is much appreciated and I hope I don't di
On 07/12/2006, at 12:42 AM, Jim Gallacher wrote:
Graham Dumpleton wrote:
There were no more comments on basic apache.import_module()
documentation so I have tweaked a few last things, committed it
and marked as resolved the final issue in JIRA tagged for 3.3.
Thus, unless anyone else has got
On 07/12/2006, at 9:14 PM, Graham Dumpleton wrote:
Once that is decided I'll roll the tarball, likely tonight. I
assume we'll use release-3-3-0b as the tag?
Based on past conventions, that tag seems appropriate. If all is
okay do we
then just retag as 3.0.1?
Hmmm, I thin
I don't see any harm. It isn't lost after all if one wants to go back
in the
revision history and get it back. :-)
On 10/12/2006, at 3:04 AM, Jim Gallacher wrote:
I stupidly tagged a branch with the wrong name (3-3-0-bc1 instead
of 3-3-0b). Should I remove it or just let it slide?
Jim
[EM
Jim Gallacher wrote ..
> Gregory (Grisha) Trubetskoy wrote:
> >
> > core +1 on releasing it into the wild
> >
> > grisha
>
> I'm not sure what we're voting on here, and I'm not sure what I meant by
> "the next level" either. :)
I'd have to concur, that not specific about what is intended.
>
This code in req.readlines() looks a bit fishy to me and possibly leaks memory.
The code in question is:
rlargs = PyTuple_New(0);
if (result == NULL)
return PyErr_NoMemory();
line = req_readline(self, rlargs);
while (line && ((linesize=PyString_Size(line))>0)) {
Py
On 16/01/2007, at 6:54 PM, [EMAIL PROTECTED] wrote:
I have this, very simple input filter
def inputfilter(filter):
if filter.req.method != 'POST':
filter.pass_on()
return
filter.req.log_error('first read')
s = filter.read()
while s:
filter.req.log_error(
On 28/01/2007, at 2:48 AM, Jim Gallacher wrote:
Howdy All,
I think it's time to push 3.3.1 out. Unless there are any
objections I'll roll the tarball tomorrow, which is to say Sunday,
or Monday as the case may be for our antipodal friends. :) ).
Since we haven't made any changes in the c
On 03/02/2007, at 8:59 AM, Nicholas Milkovits wrote:
Hi all,
I have been tasked with trying to figure out how to share one
database pool for all child processes/worker threads for a single
apache2 virtual host using mod_python. I came across this thread
from 2003
http://mail-archives.a
Clark Rawlins wrote ..
> Hello,
>
> I have a client I need to handle post requests for that uses
> Content-Encoding: xml and Transfer-Encoding: chunked.
>
> Now the Content-Encoding is no problem I plan on using sax to parse the
> content. The chunked transfer encoding is where I have run into i
The mod_wsgi module for Apache that I have been talking about for a
while now is now at a point where am happy for people to start
experimenting with it. If you don't know what I am talking about,
this is a module in the same style as mod_python, which implements the
Python WSGI specification wit
On 10/05/07, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote:
1. "Python" is not a good name for this project because "Apache Python"
will just be too confusing and probably infringes on a PSF trademark. So
if you have any creative suggestions, send them in, don't be shy, even if
you think
On 10/05/07, Jim Gallacher <[EMAIL PROTECTED]> wrote:
I like that one. Another, less scientific, possibility might be
pythonalia (python + miscellania).
That reminds me of news broadcasts where they talk about police
arresting people in possession of drug paraphernalia. :-)
In a similar extens
Not necessarily wanting to see this discussion die again, how about
just calling it the 'PythonScript' project. Name means it is still
obvious and I can't see how we would have issues with a composite name
like that as far as PSF trademark goes, but then could be wrong.
On 1
On 18/05/07, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote:
On Thu, 17 May 2007, Jim Gallacher wrote:
> Quetzalcoatl is still my sentimental favourite.
>
> Perhaps I'm overly concerned with potential search problems for
> Quetzalcoatl, considering that Google is pretty good at figuring
On 18/05/07, Daniel J. Popowich <[EMAIL PROTECTED]> wrote:
Graham Dumpleton writes:
> Read:
>
> http://www.modpython.org/live/current/doc-html/pyapi-apmeth.html
>
> Especially the area which starts just before:
>
> PythonOption mod_python.importer.path "[&#
es and the data presented
there can be helpful sometimes in seeing what is happening and working
out how the module importer works.
Graham
On 18/05/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
On 18/05/07, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
> Just change this in your mpserv
On 18/05/07, Daniel J. Popowich <[EMAIL PROTECTED]> wrote:
Graham Dumpleton writes:
> > When I go to http://localhost/~dpopowich/py/syspath, a simple
> > mpservlet that writes out the current value of sys.path, I do NOT see
> > /home/dpopowich/public_html/py in the pa
On 18/05/07, Daniel J. Popowich <[EMAIL PROTECTED]> wrote:
Graham Dumpleton writes:
> And that is what the documentation I pointed you at states:
>
> """Note that with the new module importer, as directories associated
> with Python*Handler directives are no
To confirm my vote in correct format:
+1 Quetzalcoatl
Graham
On 22/05/07, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote:
On Sun, 20 May 2007, Justin Erenkrantz wrote:
> FWIW, the full name of the TLP will be: "Apache " - so "Apache
> PyPache" doesn't roll off the tongue very well...
In 411487 it mentions:
"""So, it seems it's directly related to libmhash2 (as [2] suggests)."""
Disabling of mhash module may not be enough if one of the other PHP
modules they list in 433038 also use libmhash2 library. Quite possible
that one of the crypto libraries use it, or the ldap module me
On 31/08/2007, Robert Edmonds <[EMAIL PROTECTED]> wrote:
> Graham Dumpleton wrote:
> > In 411487 it mentions:
> >
> > """So, it seems it's directly related to libmhash2 (as [2] suggests)."""
> >
> > Disabling of mhash module
On 07/10/2007, Aaron Swartz <[EMAIL PROTECTED]> wrote:
> re: http://www.modpython.org/pipermail/mod_python/2007-June/023854.html
>
> I've found a way to make this happen repeatedly. Occurs in both 2.4.2
> and 2.5.1. I have a file where every time I read it in, I get it.
If it isn't too large, coul
Nicolas Lehuen (JIRA) wrote ..
> [
> http://issues.apache.org/jira/browse/MODPYTHON-54?page=comments#action_65702
> ]
>
> Nicolas Lehuen commented on MODPYTHON-54:
> -
>
> I have added two function to mod_python.publisher :
>
> def import_page(r
On 19/05/2005, at 7:24 PM, Nicolas Lehuen wrote:
The handle around the module worries me a bit as it would appear to
work in read mode only. Ie., not sure it would work if someone tried
to
actually set a global variable within the module from outside of it.
The lack of __setattr__() means it will
On 19/05/2005, at 8:32 PM, Nicolas Lehuen wrote:
I'm OK with reloading published modules being automagically reloaded,
but I'm not for standard Python modules. Published modules are or
should be developed with some assumptions in mind, namely that the
module can be reloaded at any time, that it can
On 19/05/2005, at 11:16 PM, Nicolas Lehuen wrote:
OTOH, you have implemented a clever import hook that allows users to
keep on using the familiar import statement, but I don't feel very
comfortable with this idea. I like the import statement semantics to
remain always the same, and the way import h
Graham Dumpleton wrote ..
> I still need to do more investigation work on the import hook to see if
> it is at all possible to override it just for specific modules, ie.,
> those loaded using the custom module loader. If I can find a way of
> doing this, then great. If not, am always
Noel J. Bergman wrote ..
> Why are you people cc'ing [EMAIL PROTECTED] with this stuff?
Sorry, simply doing reply all on mailing list to a post that originally
was generated by way of JIRA web site update. Where the web site
updates get posted to a mailing list, the JIRA email address should
possi
On 08/06/2005, at 8:33 AM, Barry Pearce wrote:
Indeed Im for fixing it...its on my list of things to do...right after
'do everything the company want RSN'
I do believe it should be mod_python that is fixed. I have a VERY big
need for reload of modules *without* taking down my server - en
An update on a few things that I have managed to get working in
Vampire in respect of some of the issues below, plus a few other
comments.
On 08/06/2005, at 6:33 AM, Nicolas Lehuen wrote:
One last thing that we should prepare is a clear and definite answer
to the zillion users who need to impor
On 08/06/2005, at 7:19 AM, Jim Gallacher wrote:
MODPYTHON-37
Add apache.register_cleanup()
According to the FAQ entry linked by Graham, this probably can't
be done, so change it's status to closed?
Actually, I still believe it can be done, but from memory Grisha
expressed
reservations a
I admit I haven't necessarily fully digested some of what has already been
proposed but, here is my take on the issue put together on main train ride
this morning to work .
I feel that there are a lot of issues which need to be covered to solve the
problems with module loading. The apache.impo
Nick wrote ..
> I agree; the code there is relatively simple and will probably do the
> job for most people. Keep it simple, and it can serve as an example for
> people who want to do something more sophisticated. Or they can upgrade
> from publisher to vampire; honestly, if you like publisher I
On 09/06/2005, at 11:15 PM, Nick wrote:
Graham Dumpleton wrote:
module, from the document tree. Maybe the context of the directive
could be used for that ; if the directive is defined at the server or
virtual host level, then it's a top level handler, otherwise if it is
defined in a Loc
On 10/06/2005, at 2:53 AM, dharana wrote:
As for vampire - why would I want vampire? mod_python is great
except this. I personally have no interest in adding yet more
software to my system just to solve the mod_python import issue - Id
rather it was fixed in the right place...not everyone uses
On 26/06/2005, at 1:28 AM, Jim Gallacher wrote:
Changed import mechanism.
(I wasn't paying too much attention to this whole discussion, so
maybe someone else could comment on how this changed and the possible
impact on user code?)
New version attribute.
Added publisher.get_page() which allows
One issue at a time sounds good. :-)
On 08/07/2005, at 11:38 PM, Gregory (Grisha) Trubetskoy wrote:
I think that the issue of import_module not honoring the AutoReload
and Debug directives (because it was originally only used internally
and was used a level "below" the directives) is a fairl
Note that this has been pushed to the mod_python developers list. It is
suggested that if you are interested in following this discussion that
you subscribe to that list instead. Anyone replying to this email please
remove the standard mod_python list from the cc to keep it just on the
developers
On 13/07/2005, at 3:32 AM, Gregory (Grisha) Trubetskoy wrote:
P.S. On magic request caching - I think that if this works, then why
not, though I think it needs to be bounced around a little more. BTW -
from the code below:
_requestCache[thread].pop()
was this meant to be
del _
> > I can see two problems here. The first is that if the target of the
> > internal redirect is a part of the URL namespace which is under the
> > control of a different handler, or where ApplicationPath option was set
> > explicitly to be different, the PYSID would potentially override a valid
>
Jim Gallacher wrote ..
> I think the automatic session unlock needs to stay. It's just too easy
> for the user to forget a manual unlock, deadlock the session and hose
> their server in very short order.
What though is the consequence of the session lock not being reacquired.
Ie., what happens if
Sorry, getting a bit overwhelmed with all these rapid changes in state
of things as bit busy today. Will probably will only know what is going
on when I look at latest code in repository. Then I'll probably pipe in
with some more pertinent comments about 3.2.
One report I would like to get some co
up().
--
Key: MODPYTHON-37
URL: http://issues.apache.org/jira/browse/MODPYTHON-37
Project: mod_python
Type: New Feature
Components: core
Versions: 3.1.4
Reporter: Graham Dumpleton
Priority: Minor
Fix For: 3.2.0
Attachments: r
Graham Dumpleton wrote ..
>
> On 09/08/2005, at 7:51 AM, Graham Dumpleton wrote:
> >> Will it introduce new and exciting locking issues for accessing the
> >> cache?
> >
> > I don't think so, the caching is effectively done on a thread specif
Have started to have a look through the latest mod_python.publisher
code, got a few comments to make about it.
First is that it has been changed to allow "HEAD" requests whereas
before it only supported "GET" and "POST". A "HEAD" request is handled
by the mod_python.publisher code saying:
A prerequisite for full JIRA access is probably going to be sending in
the
ASF committers agreement. I haven't done that as yet and so don't have
SVN
access either. I am hoping that my work load will drop after I take a
holiday in September and I'll be able to finally start taking a more
dir
On 10/08/2005, at 10:36 PM, Nicolas Lehuen wrote:
Second issue is the fact that new mod_python.publisher code uses the
req.finfo attribute. This may be convenient, but it prevents some cute
stuff being done in the future.
Actually, I used req.finfo as it allowed me to save a call to
os.stat
Apologies if this is a duplicate, mail delivery is screwing up real bad for me.
Grisha wrote ..
> > Subversion branch: tags/3-2-0-BETA1
> > mpversion.h: #define MPV_STRING "3.2.0-beta-1"
>
> There shouldn't be a number after BETA (I did this before, which is where
> you may have gotten the idea,
A few comments:
1. If you have an older version of flex than that expected, it gives
message:
checking flex version... configure: WARNING: Flex version 2.5.31 or
greater is required. The one you have seems to be 2.5.4. Use
--with-flex to specify another.
There is nothing in the README des
On 19/08/2005, at 2:59 AM, Jim Gallacher wrote:
Ron Reisor wrote:
Hello,
I ran into a problem with the loader on MacOSX.
MaxOSX 1.4.2
python 2.4.1
apache 2.0.54
The loader seems to not like the "-undefined suppress" arguments in
the final load.
I modified dist/setup.py by removing the two "-u
On 19/08/2005, at 7:57 AM, Graham Dumpleton wrote:On 19/08/2005, at 2:59 AM, Jim Gallacher wrote: Ron Reisor wrote: Hello,I ran into a problem with the loader on MacOSX.MaxOSX 1.4.2python 2.4.1apache 2.0.54The loader seems to not like the "-undefined suppress" arguments in the fi
On 19/08/2005, at 8:01 PM, Graham Dumpleton wrote:Thus, setup.py will thus need to check first whether the -undefined optionalready exists. Thus, setup.py should use:if sys.platform == "darwin": if not '-bundle' in sysconfig.get_config_var("LDSHARED")
In 3.2 beta, if one uses:
SetHandler mod_python
PythonHandler mod_python.publisher
PythonDebug On
and you DO NOT have an index.py file and use a URL where the first
URL component doesn't map explicitly to a .py file, you will get
a Python error rather than a 404 NOT FOUND response. For exa
path=[path])
File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line
454, in import_module
f, p, d = imp.find_module(parts[i], path)
ImportError: No module named index
We should create a new JIRA issue. If it turns out that the fix is not
easy, is this a big en
On 01/09/2005, at 6:19 AM, Jim Gallacher wrote:Hey Gang,I think we are ready for the 3.2.1b release. If there are no objections in the next 24 hours I'll create the package and make the announcement on python-dev.Sounds good.I'll always be hoping to sneak in just one more change (eg. MODPYTHON-73),
Jim Gallacher wrote ..
> Gregory (Grisha) Trubetskoy wrote:
> >
> > I've been away this weekend - just got back, but I'm too busy to try
> to
> > read all the multiple-interpreter related comments. I guess my question
> > is - can someone provide a quick summary of how far we are from 3.2.1b
> >
I don't use sessions enough to comment on whether this is an appropriate
change for mod_python or not, but I would suggest that you log an
enhancement request at:
http://issues.apache.org/jira/browse/MODPYTHON?report=select
This will ensure any request is not overlooked. It is also preferred
On 09/09/2005, at 10:02 AM, Jim Gallacher wrote:
As far as some future version breaking compatibility, I favour a
bigger jump in the major number: 3.2 -> 4.0. This is server software
after all, and some people may prefer to maintain an older version for
a longer period, foregoing new features
On 10/09/2005, at 2:08 AM, Gregory (Grisha) Trubetskoy wrote:
Don't know about versions, but I'd _really_ like to see a FreeBSD +1
at this point :-) Graham - don't you have FreeBSD access somewhere?
Sorry, don't have access to FreeBSD anymore. Any comments I make about
FreeBSD are from expe
Documentation says:
path_info
String. What follows after the file name, but is before
query args, if anything. Same as CGI PATH_INFO. (Read-Only)
The "path_info" member is now actually modifiable in 3.2 and
so "Read Only" designator can be dropped.
BTW, what is the timetable for actua
On 20/10/2005, at 5:49 PM, Nicolas Lehuen wrote:
> And I agree with all these points except that I don't think it's
> trivial to get it right. In fact, that it is *not* trivial may be
best
> argument for inclusion in mod_python. Having everyone write
seemingly
> trivial logging code which
On 21/10/2005, at 2:41 AM, Nic Ferrier wrote:
There is one remaining problem that I am aware of. When you do:
logger = logging.getLogger("webapp")
you are always gauranteed to get the same logger. That's bad in a
multi-programming environment.
The traditional approach to this is to creat
Graham Dumpleton wrote ..
> Hopefully everyone follows what I am talking about. I will try and get
> together a working example today of what I am talking about, but Nick,
> you may want to consider posting your code and how you are using it
> as it probably will not be too different.
Graham Dumpleton wrote ..
> Graham Dumpleton wrote ..
> > Hopefully everyone follows what I am talking about. I will try and get
> > together a working example today of what I am talking about, but Nick,
> > you may want to consider posting your code and how you are using
Nic Ferrier wrote ..
> "Graham Dumpleton" <[EMAIL PROTECTED]> writes:
>
> > That is, a global log handler instance is created once only. No instance
> per
> > request handler invocation.
> >
> > As you point out you need though to do caching of req
Nic Ferrier wrote ..
> "Graham Dumpleton" <[EMAIL PROTECTED]> writes:
>
> > Nic wrote:
> >> Programmers may or may not want to redirect logging through Apache.
> If
> >> mod_python used the system you describe there would either have to be:
&g
pache.log_error()" instead.
Graham
Nick wrote ..
> Graham Dumpleton wrote:
> > Hopefully everyone follows what I am talking about. I will try and get
> > together a working example today of what I am talking about, but Nick,
> > you may want to consider posting your code an
Nick wrote ..
> Graham Dumpleton wrote:
> > Yes, effectively the same as what I was doing. As I highlighted in prior
> > email though about request cache implementations, not sure it would
> > work correctly if an internal redirect occurred and both original handler
>
Nick wrote ..
> Graham Dumpleton wrote:
> >>Graham Dumpleton wrote:
> > Unfortunately you can't do that as all Python request objects in that
> > chain are created fresh for the handler which is the target of the
> > internal redirect. When the internal redirect
Graham Dumpleton wrote ..
> It is only recently that I realised that a nested function like that
> could access stack variables of the enclosing function.
I should have added, "when the execution of the enclosing function has
already finished and the nested function is called at a
On 22/10/2005, at 12:36 AM, Nick wrote:
Graham Dumpleton wrote:
Anyway, I have attached an updated version of my log handler. This
fixes
the issue with log levels that don't exactly map to any defined
level.
Eliminates the explicit stack for storing request objects and in
general
On 22/10/2005, at 8:05 AM, Nick wrote:
As to providing "handler()" this is again because it is a
separate sample
distinct from mod_python. If a part of mod_python that can all be
done
transparently. I didn't want to provide a sample where people had to
hack on their mod_python installation
On 22/10/2005, at 7:40 AM, Gregory (Grisha) Trubetskoy wrote:
On Fri, 21 Oct 2005, Jim Gallacher wrote:
Grisha,
I had the status of these issues flipped in my original message.
The cache problem MODPYTHON-82 *is fixed* in trunk. MODPYTHON-83
(compile problems when python is not threade
Jim Gallacher wrote ..
> Indrek Järve wrote:
> > Jim Gallacher wrote:
> >
> >> And see if any tests fail. If they pass, send a +1 to the list, if they
> >> fail, send the details (the versions of OS, Python and Apache, the test
> >> output, and suggestions, if any).
> >>
> >> Thank you,
> >> Jim Ga
Jim, is this just confirming that test shows a problem with unpatched
3.2
or when Boyan's GIL state fixes are also applied? I haven't tried the
suggested patches yet, as wanted an answer as to why GIL state API had
to be
explicitly used, which he has now done so.
Graham
On 03/11/2005, at 2:
The documentation for the Python debugger support in mod_python states:
Because pdb is an interactive tool, start httpd from the command line
with the -DONE_PROCESS option when using this directive. As soon as
your
handler code is entered, you will see a Pdb prompt allowing you to
step
Grisha wrote ..
>
> On Thu, 3 Nov 2005, Graham Dumpleton wrote:
>
> > With the thought of mod_python perhaps ignoring the PythonEnabledPdb
> > option when not run in single process mode, is there a way using the
> > apache.mpm_query() function or some other f
Graham Dumpleton wrote ..
> Grisha wrote ..
> >
> > On Thu, 3 Nov 2005, Graham Dumpleton wrote:
> >
> > > With the thought of mod_python perhaps ignoring the PythonEnabledPdb
> > > option when not run in single process mode, is there a way using the
&g
On 06/11/2005, at 2:42 AM, Jim Gallacher wrote:
The changes work fine on:
Mac OS X (10.3.9) / Apache 2.0.51 (worker) / Python 2.3 (Apple OS
Installed)
Linux Fedora Code 2 / Apache 2.0.55 (prefork) / Python 2.3.5
Test example was gilstate.tar.gz attached to MODPYTHON-77.
Also passed on mod_
On 06/11/2005, at 11:55 AM, Gregory (Grisha) Trubetskoy wrote:
On Sun, 6 Nov 2005, Graham Dumpleton wrote:
Haven't had a chance to investigate yet and ensure they aren't caused
by me
using versions of both Python and Apache not in standard locations.
Most
tests work though. The
I can't find the old mail about this, but Grisha suggested that this can occur
in virtual hosting environments, eg, OpenVPS.
Barry Pederson wrote ..
> Barry Pederson wrote:
> > I've got failures that seem to be caused by the tests themselves, but
> > with a bit of tweaking they pass.
> >
> > Free
Jim Gallacher wrote ..
> So far I have working images of Debian stable, Debian unstable and
> Gentoo, plus the afore mentioned but messed up FreeBSD. As time (and
> disk space) permit I'll add some combination of Fedora, maybe one of the
> RHEL clones, SUSE, Ubuntu or whatever else strikes my fan
r raising the MaxClients
> setting
>
> The only solution is to stop and start (not graceful restart) Apache.
>
> Cheers,
>
> Michel
>
> --On lundi 21 novembre 2005 19:28 -0500 Graham Dumpleton
> <[EMAIL PROTECTED]> wrote:
>
> > Michel Jouvin wrote ..
&g
Hmmm, go away for two days and a mail storm erupts. :-(
I may never be able to catch up and digest this mail thread, but I'll
try and add a few comments of my own.
On 01/12/2005, at 8:41 AM, Nicolas Lehuen wrote:
c) We don't have a req.base_uri (to follow Jim's naming suggestion)
or req.sc
I'm a bit confused by:
- The only trick is that you'll have to stop your Apache server
before launching
the test, as the start/stop command can only apply to one single
Apache instance.
Does this apply to UNIX as well as Win32?
I ask as I have never bothered to explicitly shut down any r
Jim Gallacher wrote ..
> Gregory (Grisha) Trubetskoy wrote:
> >
> > On Thu, 8 Dec 2005, Graham Dumpleton (JIRA) wrote:
> >
> >> In 3.2, mod_python.publisher was modified so that if it encountered
> an
> >> interable it would recursively iterate ove
201 - 300 of 1069 matches
Mail list logo
