Hi Grisha,
The mod_python information on modules.apache.org is badly out of date.
It would be a good idea to update this for 3.2.7
http://modules.apache.org/search?id=220
Jim
mation about mod_python is available at:
http://httpd.apache.org/modules/
Many thanks to Jim Gallacher, Graham Dumpleton, Nicolas Lehuen and
everyone else who contributed to and helped test this release, without
your help it would not be possible!
Regards,
Grisha Trubetskoy
ch as a 3.3 experimental
module import branch should start with an alpha character so the stable
3.x.x branches don't get lost in the noise. eg.
experimental-3.3
but not:
3.3-experimental
Jim
Gregory (Grisha) Trubetskoy wrote:
On Thu, 9 Feb 2006, Jim Gallacher wrote:
Looks good.
It looks like Grisha has updated the html and pdf docs on the website so
we are good to go.
I'd like to see a change in the way the website is handled so the
maintenance burden no longer falls on Grisha. He has paid his dues after
all. :)
Depending on Grisha's preference, I think we should
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I'd like to checkin my patch to support apache 2.2. It doesn't add any
new functionality. Any objections?
If I recollect, the only real issue was the implications on Win32 platform
of changing the APR_STATUS_IS_SUCCESS(s)
Nicolas Lehuen wrote:
Hi,
There is something I'd like to do for the 3.3 version : it is to
refactor the test suite. It's more a chore than real development, but
the current test suite is slowly becoming big and quite difficult to
maintain.
Also, I think the size and complexity may be intimidat
Gregory (Grisha) Trubetskoy wrote:
On Fri, 10 Feb 2006, Daniel J. Popowich wrote:
Could we run mod_python on apache.org's site, like, say, the current
version? ;-)
We could ask again, but last time the answer was no, and I tend to
agree.
Also agree.
But I also understand that we have
Thanks for the input Justin.
Jim
Justin Erenkrantz wrote:
On 2/9/06, Jim Gallacher <[EMAIL PROTECTED]> wrote:
I'd like to see a change in the way the website is handled so the
maintenance burden no longer falls on Grisha. He has paid his dues after
all. :)
Depending on Grisha
Justin Erenkrantz wrote:
On 2/10/06, Jim Gallacher <[EMAIL PROTECTED]> wrote:
message from Justin Erenkrantz has not shown up on list? Is Justin
subscribed? I'll cc his message to the list in a separate email.
Moderators (Joe S., Grisha, and Greg) haven't approved my e
Justin Erenkrantz wrote:
On 2/10/06, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote:
We could ask again, but last time the answer was no, and I tend to agree.
But I also understand that we have Solaris servers on which zones can be
created where we could run our own httpd.
httpd.zones
John McFarlane wrote:
I would he happy to help out if my experience would be useful.
http://thinkflat.com/home/portfolio/
Lemme know if there's anything I can do :)
Sounds good. If we have a few people involved we are more likely to stay
motivated.
I've adapted the httpd.apache.org layo
Justin Erenkrantz wrote:
On 2/11/06, Jim Gallacher <[EMAIL PROTECTED]> wrote:
The underlying html from httdp.apache.org makes heavy use of tables for
layout and formating. If we end up using this layout I'd want to rewrite
it in css. Tables are just so last century. :)
You r
The download page under the "Apache Mod_python 3.2.7 is now available"
heading states:
"It will also work with HTTP Server 2.2, but this support should be
considered experimental at this point."
This is not correct. We made the decision to not support Apache 2.2 in
this release. There is
Graham Dumpleton wrote:
Thus we come to my actual idea that I want some feedback on.
The idea is to provide a new directive in mod_python that allows you to
mark
an arbitrary point in the directory hierarchy as a context point or
base directory
from which files can then be addressed using
Graham Dumpleton wrote:
On 12/02/2006, at 2:40 PM, Jim Gallacher wrote:
Graham Dumpleton wrote:
get_directories could have several meanings in the context of a
request. Would req.get_module_directories() be a better alternative?
Does that capture the concept that you are trying to
Justin Erenkrantz wrote:
On 2/11/06, Jim Gallacher <[EMAIL PROTECTED]> wrote:
No, I was not aware that it is auto-generated, but I'm hardly suprised.
:) The point was mostly to kick off a discussion.
The point is that you needn't muck with HTML directly and can focus on
the
John McFarlane wrote:
I don't at all mean to sound confrontational, but would simple xml + xsl
be a bit easier to implement? If we're just going to have a few pages,
a simple shell script could loop thru them calling xsltproc. Then
again, I'm a fan of using simple tools for simple needs?
No,
Mike Looijmans wrote:
Oh and if we are refactoring the tests, I want a "make tests" rule. I'm
tired of doing: ./configure; make; sudo make install; make tests; DOH!
cd test; python test.py. :)
Make that "make check" (like autotools), to not confuse old-skool
autoconfers like myself.
That w
Graham Dumpleton wrote:
As Jim pointed out a while back, we need to get going on mod_python 3.3
before I fill up JIRA with another page of bug reports or suggestions.
I think you already *have* filled another page since I made that comment. ;)
That said, how do we want to proceed on this? Do
Nicolas Lehuen wrote:
Based on today's traffic on the mailing lists, I think that we should
go for a short-term 3.2.8 release of mod_python, with certified Apache
2.2 support on multiple platforms. The code is only there but I
suppose we'll need a lot of testing, so maybe we could expect to
relea
Graham Dumpleton wrote:
Grisha wrote ..
On Tue, 14 Feb 2006, Jim Gallacher wrote:
I wonder if we should generalize this, so rather than PythonMutexDir,
we have
PythonModuleConfig. Usage might look like:
PythonModuleConfig mutex_dir /path/to/mutexs
PythonModuleConfig max_mutex_locks 8
Graham Dumpleton wrote:
Is my list of suggested JIRA items then seen as being reasonable for
such a projected release?
This seems reasonable, since we have either already committed the fixes
or have patches available (I think).
Do we want to create a new JIRA issue for the mutex directory i
Nicolas Lehuen wrote:
Hi,
I've built Apache 2.2 and tested mod_python SVN trunk with it.
The two register_cleanup tests fail. Apparently it's because the test
code registers a cleanup function giving the current request as
parameter. Of course when the cleanup function is called, the request
ob
Nicolas Lehuen wrote:
2006/2/15, Jim Gallacher <[EMAIL PROTECTED]>:
Nicolas Lehuen wrote:
Hi,
I've built Apache 2.2 and tested mod_python SVN trunk with it.
The two register_cleanup tests fail. Apparently it's because the test
code registers a cleanup function giving the cu
Graham Dumpleton wrote:
Hmmm, somehow I managed to vapourise an email, didn't even get
to my sent mail box. Let me try this again.
Jim Gallacher wrote ..
Graham Dumpleton wrote:
Correct, is actually done from the mod_python module init function.
The only way one could have it dynami
Graham Dumpleton wrote:
Jim Gallacher wrote ..
If the settings are going to be a generic key/value like in
PythonOption, but only for purposes of the mod_python system itself,
maybe it should be called PythonSystemOption. Prefer PythonSystemOption
as "Module" is too confusing to me
Oden Eriksson wrote:
tisdagen den 14 februari 2006 13.17 skrev Oden Eriksson:
Hello.
[...]
I am no programmer, but can't you just look at how this is handled in the core
mod_ssl and ldap code?
That would be cheating and no fun at all! ;)
Seriously though, we do often look through the so
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Graham Dumpleton wrote ..
How does req.server.get_options() differ from req.server.get_config(),
which already exists?
I still see what is in get_config() as special, ie., the values for
actual directives. Just don't think it is good to mix
I agree with Deron's summary of your summary. :)
If we make this change (and that is a +1 from me) I suggest the
following path, assuming that it is possible to control this behaviour
with a PythonOption flag:
1. mp 3.3 - New behaviour is off by default, but can be turned on using
a PythonOp
I just noticed that "write" is declared twice in request_methods[] .
What's up with that??
src/requestobject.c
static PyMethodDef request_methods[] = {
...
... line 1075
{"write", (PyCFunction) req_write, METH_VARARGS},
...
... line 1087
{"write", (PyCFunction) r
Graham,
I don't think it's necessary to add an additional JIRA comment when you
commit some code. JIRA will pickup the svn commit as long as the issue
number is mentioned in the svn commit message. People can subscribe to
python-cvs if they want notification of the commits.
This should save
I just notice that a few files still say that mod_python uses Apache
License 1.1 (eg htdocs/tests.py, src/psp_string.c). Can I assume this is
an error and that *everything* should be version 2.0?
Jim
Graham Dumpleton wrote:
On 19/02/2006, at 3:24 PM, Graham Dumpleton wrote:
Thus depending on what you are doing, you need one or the other. To
make it
obvious, should perhaps use a distinct method name to add handlers as
stacked
handlers against the current handler list. Thus:
def all(r
Yes, this test seems to be broken. I'll create a JIRA issue for it.
We need unit tests for the unit tests. :)
Jim
For my WTF moment, have a look at test_req_get_basic_auth_pw in the
test suite. I guess it is supposed to be test req.get_basic_auth_pw (), but
that function isn't even mentioned a
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
Jim
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
Other JIRA thoughts:
Should we have a "unit test" component for bugs in the actual unit test
code?
Since we plan on having 3.2.x bugfix releases, should creat
(the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you for your assistance,
Jim Gallacher
+1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
If that is what closed implies. Is there somewhere which states what we
should interprete the different status as meaning? I don
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham,
I don't think it's necessary to add an additional JIRA comment when you
commit some code. JIRA will pickup the svn commit as long as the issue
number is mentioned in the svn commit message. People can subscribe to
python-cvs if
BTW, are we going to put up your developer guidelines anywhere for viewing?
http://www.modpython.org/pipermail/mod_python/2005-December/019712.html
Until it finds a permanent home the best place to look is here:
http://people.apache.org/~jgallacher/mod_python/website-test/developers.html
And
Graham Dumpleton wrote:
Jim Gallacher wrote ..
All very interesting, except that JIRA does record the svn commit info,
and with great detail. It just doesn't treat the commit as a comment.
For example:
http://issues.apache.org/jira/browse/MODPYTHON-124?page=all
Personally I thin
Hi Oden,
The Apache 2.2 support will likely go into the 3.2.9 bugfix release. We
just wanted to get the security problem out of the way first.
Jim
Oden Eriksson wrote:
+1 Mandriva Linux Cooker (x86_64), apache 2.2.0 mpm-prefork, python-2.4.2
Note that I applied this change:
http://issues.a
fork, python 2.4.2
Jim Gallacher <[EMAIL PROTECTED]>
+1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Graham Dumpleton wrote:
On 21/02/2006, at 7:08 AM, Jim Gallacher wrote:
The Apache 2.2 support will likely go into the 3.2.9 bugfix release.
We just wanted to get the security problem out of the way first.
Jim, if we are again going to aim for a bug rollup release for 3.2.9 do I
need to
Nice summary.
+1 for the change.
Jim
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I don't have alot more to say on these last 2 emails. I think you are on
the right path here.
Okay, I think I have a good plan now.
To summarise the whole issue, the way Apache treats multiple handle
Justin Erenkrantz wrote:
On 2/19/06, Jim Gallacher <[EMAIL PROTECTED]> wrote:
I just notice that a few files still say that mod_python uses Apache
License 1.1 (eg htdocs/tests.py, src/psp_string.c). Can I assume this is
an error and that *everything* should be version 2.0?
Yes. --
Oh crap.
I changed the License information in htdocs/tests.py and thought, "Gee
this is a simple change. No need to run the unit tests before I commit
the changes". Wrong. As it happens one of the unit tests looks at the
first line of htdocs/tests.py, which of course is now different. I've
fi
Looks good. (with Jorey's correction).
Jim
Jorey Bump wrote:
Gregory (Grisha) Trubetskoy wrote:
If you see any problems with this text, let me know.
-- Forwarded message --
Date: Sat, 12 Feb 2005 22:00:56 -0500 (EST)
From: "Gregory (Grisha) Trubetskoy" <[EMAIL PROTECTED]>
To
Now that JIRA is responding again I thought I'd update the status of
some issues.
I've created a new JIRA version for 3.2.8.
Version 3.2 is still shown as unreleased. I assume the proper action is
to rename it to 3.2.7 and mark it as released. Can someone confirm that
this is the correct acti
Graham,
The patch is faulty with the 3rd hunk getting rejected. It looks like
you generated it from an earlier revision, but one of the lines in the
hunk #3 was included in your commit for r380087. The offending line is:
+ "python_filter: Can't get/create interpreter.");
Graham Dumpleton wrote:
On 20/02/2006, at 4:22 AM, Jim Gallacher wrote:
I just notice that a few files still say that mod_python uses Apache
License 1.1 (eg htdocs/tests.py, src/psp_string.c). Can I assume this
is an error and that *everything* should be version 2.0?
Jim, I think you
Graham Dumpleton wrote:
One of the problems when I am looking at making changes to mod_python
is knowing that there is some consensus that changes are a good thing, or
at least that there is no objection.
I feel the same way. Let's establish some policy. I'll start a separate
thread for that
Graham Dumpleton wrote:
On 04/03/2006, at 4:59 AM, Jim Gallacher wrote:
More in the way of a general observation rather than on these
specific issues, but I wouldn't necessarily mark things as resolved
just on the basis of the fix being committed. For the big changes at
least, I
Graham Dumpleton wrote:
On 04/03/2006, at 4:59 AM, Jim Gallacher wrote:
More in the way of a general observation rather than on these
specific issues, but I wouldn't necessarily mark things as resolved
just on the basis of the fix being committed. For the big changes at
least, I thi
Justin Erenkrantz wrote:
On 3/4/06, Graham Dumpleton <[EMAIL PROTECTED]> wrote:
Actually, if want to get that pedantic and formalised, it does look
like one can select
an alternate workflow. The level of administration access we have
probably does
not allow us to change it, let alone see what o
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-124?page=comments#action_12369766 ]
Graham Dumpleton commented on MODPYTHON-124:
req.ap_auth_type is called what it is and is a member as that is what it is called i
+1
Graham Dumpleton wrote:
I have had patches for adding server side include support into
mod_python ready for a while now. See:
https://issues.apache.org/jira/browse/MODPYTHON-104
In short, it would add the ability to add Python code into files
being served up through the INCLUDES output fi
Gregory (Grisha) Trubetskoy wrote:
I don't understand this enough to have an opinion on it, seems like
another way to skin a cat,
Yes, but perhaps just for small cats. ;)
Quoting from http://httpd.apache.org/docs/1.3/howto/ssi.html
"SSI is certainly not a replacement for CGI, or other tech
I figured it was a mistake to do this late at night. :(
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-131?page=comments#action_12369959 ]
Graham Dumpleton commented on MODPYTHON-131:
In respect of:
http://s
Graham Dumpleton wrote:
This bit is going to change anyway when I add the PythonOption
mod_python.mutex_directory support. I have the changes ready, but I
think I'll review them in the morning rather than committing now.
I decide to do this stuff in 2 steps:
1. configure option
2. PythonOp
ead with adding req.get_session() at
this time. At least not how it was envisaged to be done previously.
I'll come back with a bit of analysis after I review where we were
up to previously.
Graham
On 12/03/2006, at 8:47 AM, Jim Gallacher (JIRA) wrote:
[ http://issues.apache.org/jira/brow
Graham Dumpleton wrote:
Grisha wrote ..
On Mon, 13 Mar 2006, Graham Dumpleton wrote:
Thus I want a documented convention that if a handler is going to use
util.FieldStorage, that it should before doing so, first check whether
an existing instance resides as req.form and use that instead.
I
Mike Looijmans wrote:
I'm currently using a 'private' patch, but I would really like to see
this one incorporated in some release:
http://issues.apache.org/jira/browse/MODPYTHON-93
The patch is there, all unit tests pass, and I've been torturing it
myself for a while now.
What else can (mus
I find I work more effectively when I have deadlines to worry about
(being a procrastinator by nature), so I thought I'd propose the
following roadmap.
Mar 20: 3.3-dev - snapshot for testing
Apr 1: 3.2.9 - bugfix release
May 1: 3.3-dev - snapshot for testing
Jun 15: 3.3-dev - snapsh
Graham Dumpleton wrote:
Jim Gallacher wrote ..
The idea of something like req.get_session() is to give users an obvious
way to grab a session object without the deadlock concerns. How many
times have we seen this kind of problem-code on the mailing list?
def index(req):
sess
Gregory (Grisha) Trubetskoy wrote:
On Mon, 13 Mar 2006, Jim Gallacher wrote:
The idea of something like req.get_session() is to give users an
obvious way to grab a session object without the deadlock concerns.
How many times have we seen this kind of problem-code on the mailing
list?
def
Debian Sid (httpd and python2.3 are stock debian):
$ /usr/bin/apxs2 -q CPPFLAGS
$ grep _FILE_OFFSET_BITS /usr/include/python2.3/pyconfig.h
#define _FILE_OFFSET_BITS 64
Jim
Gregory (Grisha) Trubetskoy wrote:
Could folks with access to different OS's try the following:
Compare output of "apxs
+1
Commit it. The point of the snapshot is encourage testing to catch
problems earlier in the development cylce.
Jim
Graham Dumpleton wrote:
On 14/03/2006, at 12:23 PM, Jim Gallacher wrote:
I find I work more effectively when I have deadlines to worry about
(being a procrastinator by
Graham Dumpleton wrote:
Now that I have some time, I'll explain why I want your reasoning. I
didn't have the time when I sent original email.
The only reason I can think of for Session not to generate a cookie is
because the SID is being extracted from the URL or is being passed by
some mechanis
Firat KUCUK wrote:
Graham Dumpleton yazmış:
Firat KUCUK wrote ..
Hi,
i have a little problem about Directory Index.
this is our .htaccess file:
Allow from All
AddHandler mod_python .py
PythonHandlerwepy.handler
PythonDebug On
DirectoryIndex index.htm index.html i
uggestions, if any).
Thank you for your assistance,
Jim Gallacher
+1 Linux Debian Sid, apache 2.0.55 mpm-prefork, python 2.3.5
+1 Linux Debian Sid, apache 2.2.0 mpm-prefork, python 2.4.2
New Importer:
+1 Linux Debian Sid, apache 2.0.55 mpm-prefork, python 2.3.5
+1 Linux Debian Sid, apache 2.2.0 mpm-prefork, python 2.4.2
Jim Gallacher wrote:
mod_python-3.3.0
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
On 23/03/2006, at 5:06 AM, Jim Gallacher wrote:
That's another reason to rewrite the unit tests. It's too hard to
sort out the wheat from the chaff.
I don't think this is related to your failing test, but I noticed
Hi Graham,
+1 auto update req.finfo when req.filename changed.
Is there a use case where the user might change filename but not want
finfo to change? I can't think of one, so let's save the user some work
and make their code more robust to boot.
A point I'd like to address is your concern ab
Nicolas Lehuen wrote:
Hi,
Just FYI, here are the results of my latest build & tests with mod_python
SVN revision 387864 :
+1 ActivePython 2.4.2.10 / Apache 2.0.55 / Windows XP SP2 / old importer
+1 ActivePython 2.4.2.10 / Apache 2.0.55 / Windows XP SP2 / new importer
+1 ActivePython 2.3.5.? / A
Graham Dumpleton wrote:
Nicolas
Are you okay with:
http://issues.apache.org/jira/browse/MODPYTHON-81
Pickling/unpickling top-level functions defined in published
module no longer works in mod_python 3.2
being resolved as "Won't Fix" and then closed?
As I describe in:
http://www.dscp
Graham Dumpleton wrote:
In:
http://issues.apache.org/jira/browse/MODPYTHON-117
I describe the idea of having a means of using PythonImport to define a
module to be imported into any interpreter that may be created. For some
cases where there are a lot of virtual hosts, this may be simpler tha
her import TestOnlyThis
if __name__ == '__main__':
unittest.main(module=__import__(__name__))
##
Because some tests take very long to run (in my vocabulary, "long" means
more than a second), this saves me a lot of time when working on a part
of a big project, where I don
Graham Dumpleton wrote:
I have just added to mod_python in subversion a req.discard_request_body()
method. This is a direct wrapper for underlying ap_discard_request_body()
function in C API.
The purpose of the underlying function is as described in documentation
attached to prorotype in headers
I'll take a look at the code tonight.
Jim
Graham Dumpleton wrote:
With FieldStorage being discussed on main user mailing list, came across
this old post of the mailing list:
http://www.modpython.org/pipermail/mod_python/2001-November/012256.html
What it is saying is that some HTTP clients u
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-158?page=comments#action_12373817 ]
Graham Dumpleton commented on MODPYTHON-158:
With "__file__" output, last case now looks like:
[Mon Apr 10 16:29:09 2006] [error
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Jim Gallacher wrote ..
WRT to 3.2.9, I've been bogged down with other stuff and will likely
be
fairly busy this week as well. How be we aim for a release somewhere
around April 22? I'd like to sort out why the apache 2.2 auth
Graham Dumpleton wrote:
Jim Gallacher wrote ..
WRT to 3.2.9, I've been bogged down with other stuff and will likely be
fairly busy this week as well. How be we aim for a release somewhere
around April 22? I'd like to sort out why the apache 2.2 auth test fails
on some platforms
;s a little too ugly to be
shown in public. ;)
Jim
Graham
On 11/04/2006, at 12:47 PM, Jim Gallacher wrote:
Here is the list of things I still need to backport. Fixes have
already been committed to trunk.
MODPYTHON-77
The Simplified GIL Aquisition patches.
MODPYTHON-94
Support for o
Jim Gallacher wrote:
I'm not sure about the most elegant way to handle this situation.
Perhaps something like:
#if !AP_MODULE_MAGIC_AT_LEAST(20050127,0)
#ifndef(AP_REG_EXTENDED)
typedef regex_t ap_regex_t;
#define AP_REG_EXTENDED REG_EXTENDED
#define AP_REG_ICASE REG_ICASE
#endif
#
Graham Dumpleton wrote:
The util.FieldStorage class, plus parse_qs and parse_qsl functions take a
parameter called strict_parsing. All the documentation says is:
The \var{strict_parsing} argument is not yet implemented.
Ie., it doesn't even say what it is meant to be for.
Does anyone know w
We are slowly acquiring a number of "reserved" PythonOption keywords
which should likely be collected in one place so we don't end up with
any name collisions. Does the PythonOption page in section 5.4.10 seem
most appropriate? eg.
http://www.modpython.org/live/current/doc-html/dir-other-po.ht
This seems like a good plan. I'll make the changes to the code and docs
- I don't want you to do all the work Graham. ;)
Jim
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12376137 ]
Graham Dumpleton commented on MODPYTHON-127:
--
Graham Dumpleton (JIRA) wrote:
The actual function in Apache which can be used to normalise paths and which
outputs the POSIX style path required is apr_filepath_merge(). The question is,
should this be exposed in some way so that it is useable from mod_python, or
for the req.filename case, s
Jeff Hinrichs - DM&T wrote:
I can help test mod_python if needed. I run on FreeBSD 6 with Python 2.4.3
I've got the trunk checked out and built and can submit "make check"
results when appropriate/helpful.
Hi Jeff,
Test away. :) I don't think the development trunk has been given a
workout on
I used pylint to assist in cleaning up the indentation mess in util.py.
I ended up checking all our lib/python/mod_python/*.py code, and
needless to say the results were edifying. The output is rather
extensive, with a lot noise regarding missing docstrings and the like,
but I suspect combi
Laurent Blanquet wrote:
Hello,
I'm using MOD_APACHE 3.2.8 (from binary dist). with Apache 2.0.55 under Windows
XP Pro.
I encounter memory leaks (~ 16 Ko per request) with a very basic handler like :
import mod_python
from mod_python import util
def handler(req):
F=util.FieldStorage( req )
Jim Gallacher wrote:
Laurent Blanquet wrote:
Hello,
I'm using MOD_APACHE 3.2.8 (from binary dist). with Apache 2.0.55
under Windows XP Pro.
I encounter memory leaks (~ 16 Ko per request) with a very basic
handler like :
import mod_python
from mod_python import util
def handler(req):
Jim Gallacher wrote:
Laurent Blanquet wrote:
Hello,
I'm using MOD_APACHE 3.2.8 (from binary dist). with Apache 2.0.55
under Windows XP Pro.
I encounter memory leaks (~ 16 Ko per request) with a very basic
handler like :
import mod_python
from mod_python import util
def handler(req):
Laurent,
Could you run a couple of more tests?
test1.py
from mod_python import apache, util
def handler(req):
pqs = util.parse_qsl('foo=a&bar=b')
req.content_type = 'text/plain'
req.write('mod_python.util.parse_qsl')
return apache.OK
test2.py
from mod_python i
Max Bowsher wrote:
MODPYTHON-93, r387693, backported in r393781, changes the API of
mod_python.util.Field().
I think that it would be a very bad thing to change an API in an
incompatible way in a patch release - whilst people are likely to
understand that things may break going from 3.2.x to 3.3
looks good, I'll tag it svn and create a 3.2.9 final
tarball.
Thank you for your assistance,
Jim Gallacher
Hold off on the testing.
I just realized the additional fix for MODPYTHON-84 didn't get
committed, so I'm going to roll a 3.2.9-rc2 candidate.
Jim
Jim Gallacher wrote:
The mod_python 3.2.9-rc1 tarball is available for testing. This release
adds support for apache 2.2 as well as
any).
If this tarball looks good, I'll tag it svn and create a 3.2.9 final
tarball.
Thank you for your assistance,
Jim Gallacher
1 - 100 of 602 matches
Mail list logo