Gregory (Grisha) Trubetskoy wrote:
I like Quetzalcoatl and PyPache.
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 out
spelling errors. Also the mod_python
Gregory (Grisha) Trubetskoy wrote:
So I think we've got (in no particular order):
PythonScript
Pythonidae
PyPache
pythonalia
Quetzalcoatl
Asphyxia
Scales
Pythonistas
PigeonPy
Pungi
Would people (ANYONE here on the list, yes, that includes *YOU*) please
respond with the one they like most and
How about this last minute entry as a place to keep our snake?
Apache Terrarium
Jim
Gregory (Grisha) Trubetskoy wrote:
So I think we've got (in no particular order):
PythonScript
Pythonidae
PyPache
pythonalia
Quetzalcoatl
Asphyxia
Scales
Pythonistas
PigeonPy
Pungi
Would people
Roy T. Fielding wrote:
On Feb 7, 2007, at 6:47 PM, Roy T. Fielding wrote:
The vote shall be open 72 hours or until all of the mod_python
core group members have voted, whichever is earlier.
Well, I didn't get enough responses, so this will have to wait
until after folks figure out what to do
I think we have sufficiently tested 3.3.1 and it is time for the core
group to vote on a release.
This vote is only open to the mod_python core group (Grisha, Nicolas,
Graham and myself) and is binding. We need at least three +1 votes for
the release to proceed. A -1 from any of the four
to include the
mod_python version in this string as that information is available in
the email subject. Who knows, one day I may actually write a script to
extract this information automatically. :)
Thank you for your assistance,
Jim Gallacher
On Mon, Jan 29, 2007 at 09:32:36AM -0500, Jim Gallacher wrote:
The mod_python 3.3.1 tarball is available for testing. Hopefully
Nicolas will have a chance to create Windows installers for testing in
the next couple of days.
There have been no changes in the code since
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 code base it should be just a
matter of a few people
We don't seem to be getting any more feedback on 3.3.0b (+1's across the
board), so how does everyone feel about rolling out 3.3.1 this weekend?
Or should we wait another week?
3.3.0b test result summary:
+1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1
+1 Linux Debian 3.1 Sarge,
Clodoaldo wrote:
In 4.8.1 of the 3.3 manual, last paragraph of the Session class:
you should instead use the now obsolete session option instead.
The word instead is repeated.
Thanks. Corrected in trunk.
Jim
releasing quick
fixes for 3.2. There is no reason why we can't do the same with 3.3, so
my inclination is to do an official 3.3.0 final release now rather than
later.
Jim
On Mon, 11 Dec 2006, Jim Gallacher wrote:
Test results so far, FYI. How long shall we wait until we kick it up
to the next
Graham Dumpleton wrote:
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
-worker), Python 2.4.3
+1 Linux Ubuntu 6.10, Apache 2.0.55 (mpm-prefork), Python 2.4.4c1
Jim Gallacher wrote:
The mod_python 3.3-0b tarball is available for testing. Hopefully
Nicolas will have a chance to create Windows installers for testing in
the next couple of days.
Here are the rules
Graham Dumpleton wrote:
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
Clodoaldo wrote:
2006/12/3, Graham Dumpleton [EMAIL PROTECTED]:
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
Graham Dumpleton wrote:
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
Graham Dumpleton wrote:
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. :-)
It would seem LaTeX doesn't like naked tilde characters, as ~ is used
for markup. Something like:
The
Jim Gallacher wrote:
Graham Dumpleton wrote:
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. :-)
It would seem LaTeX doesn't like naked tilde characters, as ~ is used
for markup
Jim Gallacher wrote:
Jim Gallacher wrote:
Graham Dumpleton wrote:
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. :-)
It would seem LaTeX doesn't like naked tilde characters
[ http://issues.apache.org/jira/browse/MODPYTHON-19?page=all ]
Jim Gallacher resolved MODPYTHON-19.
Fix Version/s: 3.3
Resolution: Fixed
CategorySecurity and SecurityConsiderations sections have been added to the
mod_python wiki. Links
Jorey Bump wrote:
Hi, Jim:
Jim Gallacher wrote:
The following page has been changed by JoreyBump:
http://wiki.apache.org/mod_python/MostMinimalRequestHandler
--
Let's begin at the beginning. Here is the most
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 problem and used the
LD_PRELOAD=/lib/libc_r.so fix, which
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Mod_python Wiki for
change notification.
The following page has been changed by MartinStoufer:
http://wiki.apache.org/mod_python/Session_use_with_classes
The comment on the change is:
A good start.
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 'double' to 'long', possible loss of data
are the result of converting apr_time_t from microseconds
[
http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12449192
]
Jim Gallacher commented on MODPYTHON-202:
-
We seem to be going pretty far down the road with PythonOption and our
new namespace, so I'm inclined
assistance,
Jim Gallacher
-worker), Python 2.4.4
+1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.5
Jim Gallacher wrote:
The mod_python 3.3-0-dev-20061109 tarball is available for testing.
We are almost ready for a 3.3.0 release. It's been a while since we've
had extensive testing of trunk and I think it would be wise
Jorey Bump wrote:
Jim Gallacher wrote:
The mod_python 3.3-0-dev-20061109 tarball is available for testing.
As this is a minor version bump, is there a link to the changelog so we
know what new behaviour to expect/test?
Take a look at doc-html/app-changes-from-3.2.10.html in the tarball
Jorey Bump wrote:
Jim Gallacher wrote:
Jorey Bump wrote:
Jim Gallacher wrote:
The mod_python 3.3-0-dev-20061109 tarball is available for testing.
As this is a minor version bump, is there a link to the changelog so
we know what new behaviour to expect/test?
Take a look at doc-html/app
unresolved externals
What are these functions?
- Jeff
- Original Message - From: Jim Gallacher [EMAIL PROTECTED]
To: python-dev list python-dev@httpd.apache.org
Sent: Thursday, November 09, 2006 9:00 AM
Subject: mod_python 3.3.0-dev-20061109 available for testing (release
candidate
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585 ]
Graham Dumpleton commented on MODPYTHON-202:
A configuration option can possibly be modelled off how the AcceptMutex
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham Dumpleton (JIRA) wrote:
[
http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585
]
Graham Dumpleton commented on MODPYTHON-202:
A configuration
[
http://issues.apache.org/jira/browse/MODPYTHON-172?page=comments#action_12447658
]
Jim Gallacher commented on MODPYTHON-172:
-
[[ Old comment, sent by email on Fri, 07 Jul 2006 21:26:01 -0400 ]]
I've been working through
[
http://issues.apache.org/jira/browse/MODPYTHON-184?page=comments#action_12447666
]
Jim Gallacher commented on MODPYTHON-184:
-
[[ Old comment, sent by email on Wed, 16 Aug 2006 17:44:21 -0400 ]]
Actually I don't think
Graham Dumpleton wrote:
Incomplete documentation. For AddHandler it would always have required
the .psp_ extension case to be listed explicitly.
I'll fix the docs.
Jim
On 05/11/2006, at 3:04 AM, Jim Gallacher wrote:
I was doing a bit of work on the Docs and I noticed a problem
however. I'd be pretty surprised if we could go directly from trunk to
3.3.0-final anyway.
Jim
Graham
On 05/11/2006, at 8:35 AM, Jim Gallacher wrote:
It sure feels like we are close thanks to Graham's hard work. I've
been doing some testing and it's looking good.
With 3.3.0-dev-20061104
:26 AM, Jim Gallacher (JIRA) wrote:
ReportError in importer.py raises an exception for mal-formed psp
-
Key: MODPYTHON-201
URL: http://issues.apache.org/jira/browse/MODPYTHON-201
Project
[ http://issues.apache.org/jira/browse/MODPYTHON-201?page=all ]
Jim Gallacher closed MODPYTHON-201.
---
Fix Version/s: 3.3
Resolution: Fixed
Already fixed in a more recent commit.
ReportError in importer.py raises an exception for mal-formed psp
I was fixing a error in the new mp_conn.log_error method and I noticed
that the connobject struct has a PyObject *server element. There is no
corresponding apache conn_rec-server attribute, I don't see it being
used anywhere in our code, and it is undocumented in mp_conn members.
See
It sure feels like we are close thanks to Graham's hard work. I've been
doing some testing and it's looking good.
With 3.3.0-dev-20061104 (r471260):
+1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.3.5
+1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.4.1
+1
every time if the fix is not applied. We have to run on Windows
(long story there) and need to run long term leak-free.
Thanks,
Jeff
- Original Message - From: Jim Gallacher [EMAIL PROTECTED]
To: python-dev@httpd.apache.org
Sent: Saturday, November 04, 2006 4:35 PM
Subject: Are we ready
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=all ]
Graham Dumpleton resolved MODPYTHON-127.
Resolution: Fixed
For now I have just made the tests use the new option names. There is obviously
a risk
Jim Gallacher wrote:
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Although there is no JIRA issue for it, I'd like to see us do a quick
code cleanup. I see lots of complier warnings about unused variables and
it would be nice to excise the offending bits of code. I figure we are
more likely
[ http://issues.apache.org/jira/browse/MODPYTHON-53?page=all ]
Jim Gallacher resolved MODPYTHON-53.
Resolution: Fixed
Show link for subversion and JIRA on www.mod_python website
Graham Dumpleton wrote:
On JIRA, the following issues are still marked as incomplete for mod_python
version 3.3. I have noted my own comments about where they are up to and
what I think still needs to be done.
MODPYTHON-93 Improve util.FieldStorage efficiency.
This was actually marked as
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham Dumpleton wrote:
On JIRA, the following issues are still marked as incomplete for mod_python
version 3.3. I have noted my own comments about where they are up to
and
what I think still needs to be done.
MODPYTHON-93 Improve
[ http://issues.apache.org/jira/browse/MODPYTHON-182?page=all ]
Jim Gallacher resolved MODPYTHON-182.
-
Resolution: Fixed
Memory leak in request readline()
-
Key: MODPYTHON-182
URL
Woot Woot Woot! We have our wiki!
http://wiki.apache.org/mod_python/
Now comes the hard part... what the heck are we going to do with it? :)
Jim
Dan Eloff wrote:
Unrelated question, is it ok to use the trunk in a development
environment? It will usualy work, or should I expect it to blow up in
my face more often than not?
At this point in the development cycle you are fairly safe. As later
messages in this thread indicate you've been
Since there doesn't seem to any movement on our request to ASF
infrastructure for our wiki, and after seeing yet another thread of
installation woes on the the user list, I'm thinking we should at least
buff up the installation and trouble shooting section of the docs. It'll
be a race to see
Alan Kennedy wrote:
Greetings,
I think the following may be a bug in mod_python. I can't seem to find a
bug database or tracker for mod_python?
http://issues.apache.org/jira/browse/MODPYTHON
No time to investigate right now. I'll take a look tonight.
Jim
When subscripted access is used to
[
http://issues.apache.org/jira/browse/MODPYTHON-187?page=comments#action_12431099
]
Jim Gallacher commented on MODPYTHON-187:
-
Confirmed for Apache 2.0.55 mpm-worker (Linux Ubuntu 6.0.6), execpt I get a
segfault rather than a hang
[ http://issues.apache.org/jira/browse/MODPYTHON-187?page=all ]
Jim Gallacher updated MODPYTHON-187:
Attachment: MP187-2006-08-28-jgallacher-1.diff
I hope I have the reference count right!
Hang on subscripted access to request.subprocess_env
David Fraser wrote:
David Fraser wrote:
Graham Dumpleton wrote:
On 18/08/2006, at 7:48 PM, Richard Lewis wrote:
On Tuesday 15 August 2006 23:31, Graham Dumpleton wrote:
Richard Lewis wrote ..
Do you mean that there will be no opportunity to have code run at
server
shutdown?
Correct. Reason
Justin Erenkrantz wrote:
On 8/17/06, Graham Dumpleton [EMAIL PROTECTED] wrote:
Also, dist/setup.py in mod_python source contains:
...
But I think this was a workaround for older version of Mac OS X.
What is the actual error you are getting when building?
Um, how are you building?
Per
Alexis Marrero wrote:
Jim,
This are my results for the memory leak search in apache.table().
The table object creates a memory pool by using apr_pool_create_ex() and
destroys the pool using apr_pool_destroy(). I added a line in
MpTable_New() before return (PyObject*)t to destroy the pool
Graham Dumpleton wrote:
On 14/08/2006, at 1:42 AM, Jim Gallacher wrote:
Lets target this to be done for 3.3. We just need some agreement that
proposed names are okay, plus a consensus on how we go about
deprecating old names. Do we have an option now which if enabled
prohibits use of old
[ http://issues.apache.org/jira/browse/MODPYTHON-185?page=all ]
Jim Gallacher resolved MODPYTHON-185.
-
Fix Version/s: 3.3
Resolution: Fixed
_psp.parsestring doesn't check for empty values
other bug in mp_table.
BTW, thanks for the time you've spent digging into these leaks.
Jim
/amn
On Aug 13, 2006, at 12:01 PM, Jim Gallacher (JIRA) wrote:
Memory leak apache.table()
--
Key: MODPYTHON-184
URL: http
Graham Dumpleton wrote:
On 14/08/2006, at 12:29 AM, Jim Gallacher wrote:
Anyway, if we can make a decision that we will make new importer the
default in 3.3 that would be great and would allow me to progress with
other
ideas. When I have raised this question before though, never really
Graham Dumpleton wrote:
On 13/08/2006, at 12:35 AM, Jim Gallacher wrote:
Graham,
In your JIRA cleanup session you made the comment a number of times that
the new importer is not likely to be the default in 3.3. I'm just
wondering why it can't be the default, with the old importer
I've committed the current version of my memory leak test harness to
svn. It lives in branches/jgallacher/tools/leaktest
It's a *nix only tool, originally developed on Ubuntu Dapper Drake, so
you may need to hack it a little to get it to work smoothly on other
platforms. That being said, it's
I like this proposal. The PythonAllowOverride -whatever in particular is
something that has great appeal.
Jim
Graham Dumpleton (JIRA) wrote:
Stop Python directives being used in .htaccess files.
-
Key: MODPYTHON-183
):
line = req.readline()
if not line:
break
count += 1
req.write('ok readline: %d lines read' % count)
return apache.OK
Jim
Jim Gallacher wrote:
I'll have some time to investigate this over the next couple of days. I
ran my leaktest script for FieldStorage
Nicolas Lehuen wrote:
Hi Earle,
Thanks for your input.
For the sake of performance, you way want to call a single DELETE FROM
session WHERE accessed ? request instead of fetching all the session id
and access time from the database and calling a delete per session. See for
example this
- that's
when you are geographically in a different place with slow internet
access and read only some of your e-mail ;-)
+1 for core vote (with the note about the 2.2.2 XP SP2 issue).
Grisha
On Sat, 8 Jul 2006, Graham Dumpleton wrote:
On 08/07/2006, at 4:26 AM, Jim Gallacher
Here is further confirmation that it leaks like crazy for:
mod_python 3.2.10, Linux Ubuntu 6.06, Apache 2.0.55 (mpm-worker), Python
2.4.3
Jim
Graham Dumpleton wrote:
I get it on Apache 2.0.59 as well. :-(
I will thus be interested to see what others get, as appears to be an existing
Max Bowsher wrote:
Graham Dumpleton wrote:
Okay, found the source of the memory leak. The problem goes right back
to 3.1.4 which also has the problem when tested.
...
Now what do we do about 3.2.10? Given that this thing leaks really badly
when triggered shows that no one must be using
[ http://issues.apache.org/jira/browse/MODPYTHON-168?page=all ]
Jim Gallacher resolved MODPYTHON-168.
-
Fix Version/s: 3.3
Resolution: Fixed
psp_parser fails when CR is used as a line terminator
Graham Dumpleton wrote:
Jim
Can you confirm that:
https://issues.apache.org/jira/browse/MODPYTHON-168
has actually been fixed in 3.3 and we can mark this as fixed in that
version.
Looks like it is fixed to me.
Yes, and I just mark it as such.
Jim
Graham Dumpleton wrote:
The outcome of incompatibilities between Trac and changes made to
FieldStorage in
mod_python 3.2.9 resulted in us reversing out the changes. The thought I
expressed
at the time was that we keep what would be incompatible code for
mod_python 3.3
on the basis that next
I'll deal with it.
Jim
Gregory (Grisha) Trubetskoy wrote:
This was sent to me directly, anyone willing to act on it? (I don't have
the CPU cycles right now).
-- Forwarded message --
Date: Mon, 17 Jul 2006 18:12:07 +0200
To: [EMAIL PROTECTED]
Subject: new mod_python faq
Shall we proceed with a 3.2.10 release with the current memory leak
fixes, or keep digging for more leaks?
Seeing as it's summer for most of us (except for Graham), I get the
feeling people don't have a lot of free time to spend on mod_python
right now. Personally I think we should release 3.2.10
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Shall we proceed with a 3.2.10 release with the current memory leak
fixes, or keep digging for more leaks?
Seeing as it's summer for most of us (except for Graham), I get the
feeling people don't have a lot of free time to spend on mod_python
Graham Dumpleton wrote:
On 09/07/2006, at 7:46 PM, Nicolas Lehuen wrote:
OK, I'm currently checking in the fixes you suggested on the trunk.
Too bad we cannot write a unit test that checks for memory leaks.
Jim, Graham, what shall we do for the 3.2.9 release ? Shall we keep on
with the
Nicolas Lehuen wrote:
OK, I'm currently checking in the fixes you suggested on the trunk. Too bad
we cannot write a unit test that checks for memory leaks.
I'm working on a test harness - Linux only at this point. I don't think
it would be a good idea to incorporate it into the current unit
Harold J. Ship wrote:
I presume you mean, 3.2.10?
Yes.
-Original Message-
From: Jim Gallacher
+1 skip the 3.2.9 release
+1 backport to 3.2.x
+1 release 3.1.10 asap
Hi Harold,
I just wanted to let you know you are not being ignored. I just need
some free time to dive into this - hopefully this weekend.
Jim
Harold Ship (JIRA) wrote:
[
http://issues.apache.org/jira/browse/MODPYTHON-172?page=comments#action_12419728
]
Harold Ship commented on
Graham Dumpleton wrote:
On first look I would agree there is possibly a problem. There also
would appear to be
similar issues in other parts of mod_python. For example in
cfgtree_walk() of util.c it has:
PyObject *t = Py_BuildValue((s, s), dir-directive, dir-args);
if (!t)
Reporter: Jim Gallacher
Assigned to: Jim Gallacher
Priority: Minor
A bug in req_readlines(sizehint) in requestobject.c causes output to be
returned prematurely for any value of the optional sizehint argument.
The faulty bit of code is:
line = req_readline(self, rlargs);
while
Here are the test results for 3.2.9 release candidate 3.
+1 FreeBSD 6.1 / Apache 2.2 / Python 2.4.3
+1 Linux Debian Sid, apache 2.0.55, python 2.3.5
Linux (Fedora Core 4) on Intel x86, Apache 2.0.58, Python 2.4.3
+1 Linux Slackware 10.1, Apache 2.0.55, Python 2.4.1
+1 Linux Slackware 10.2, Apache
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=all ]
Jim Gallacher reopened MODPYTHON-93:
Reopened issue due to problems experienced by some applications such as Trac.
We'll need to re-examine the code committed to make sure
. There is no need to include the
mod_python version in this string as that information is available in
the email subject. Who knows, one day I may actually write a script to
extract this information automatically. :)
Thank you for your assistance,
Jim Gallacher
+1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5
Jim Gallacher wrote:
The mod_python 3.2.9 tarball is available for testing.
This tarball is unchanged from 3.2.9-rc3, but should be retested anyway
- just in case something went pair-shaped in the process of tagging and
packaging
Mike Looijmans wrote:
Having written most of the issue 93 code, here's my opinion:
* How much non-compatibility is acceptable in a patch release?
None.
Though it hurts my personal feelings that my patch did manage to break
something (who imagined anyone trying to hack data into the FS
for your assistance,
Jim Gallacher
+1 Linux Debian Sid, apache 2.0.55, python 2.3.5
Jim Gallacher wrote:
The mod_python 3.2.9-rc3 tarball is available for testing. This release
adds support for apache 2.2 as well as some other useful backports from
the development branch. For information on the changes from 3.2.8 take a
look
Max Bowsher wrote:
Jim Gallacher wrote:
The mod_python 3.2.9-rc2 tarball is available for testing.
Something about the mod_python.util changes has either exposed a bug in
Trac, or introduced a bug into mod_python - I'm not sure which yet.
3.2.x r416547 with r393781 reverted works fine
Max Bowsher wrote:
Jim Gallacher wrote:
Max Bowsher wrote:
Jim Gallacher wrote:
The mod_python 3.2.9-rc2 tarball is available for testing.
Something about the mod_python.util changes has either exposed a bug in
Trac, or introduced a bug into mod_python - I'm not sure which yet.
3.2.x
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
DbmSession creates world readable db file
-
Key: MODPYTHON-173
URL: http://issues.apache.org/jira/browse/MODPYTHON-173
Project: mod_python
Type: Bug
Components: session
Versions: 3.2.8
Reporter: Jim Gallacher
[
http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12417405
]
Jim Gallacher commented on MODPYTHON-93:
As part of the improvments to FieldStorage, the Field class __init__ method was
changed in trunk (3.3-dev) and backported
looks good, I'll tag it svn and create a 3.2.9 final
tarball.
Thank you for your assistance,
Jim Gallacher
, if 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
[ http://issues.apache.org/jira/browse/MODPYTHON-84?page=all ]
Jim Gallacher resolved MODPYTHON-84:
Fix Version: 3.2.8
(was: 3.2.7)
Resolution: Fixed
req.sendfile(filename) sends an incorrect number of bytes when
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=abar=b')
req.content_type = 'text/plain'
req.write('mod_python.util.parse_qsl')
return apache.OK
test2.py
from mod_python
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):
F
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):
F
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
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,
1 - 100 of 328 matches
Mail list logo
