mod_python 3.2.x branch built, installed and tested (python test.py)
succesfully on
FreeBSD lakota.dundeemt.pri 6.0-RELEASE-p6 FreeBSD 6.0-RELEASE-p6 #0:
Wed Apr 5 23:27:07 CDT 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386
I did receive the following warning during the test
works in mod_python 3.2
--
Key: MODPYTHON-81
URL: http://issues.apache.org/jira/browse/MODPYTHON-81
Project: mod_python
Type: Bug
Components: importer
[ http://issues.apache.org/jira/browse/MODPYTHON-81?page=all ]
Graham Dumpleton closed MODPYTHON-81:
-
Pickling/unpickling top-level functions defined in published module no
longer works in mod_python 3.2
[ http://issues.apache.org/jira/browse/MODPYTHON-65?page=all ]
Graham Dumpleton closed MODPYTHON-65:
-
3.2 working version will not install on Mac OS X (10.3.7)
-
Key: MODPYTHON-65
On Thu, 9 Feb 2006, Jim Gallacher wrote:
Looks good. As soon as you make the official announcement I'll create
branches/3.2.x in svn and we can start on 3.3.
I don't think we need to wait for the announcement - 3.2.7 is already out
if you look on the download page, the announcement is more
I've created the a 3.2.x branch. Just so we are all clear, the
branches/3.2.x branch gets bug fixes *only*. This will be the source
repository for future 3.2 bug fix releases. New features and major code
modifications continue to go into trunk.
I think any other new branches we create
In a hurry, so a quick note. In 3.2, mod_python.publisher was changed
to read:
if req.method!='HEAD':
# TODO : the problem is that a handler can still use
req.write
# and break the assumption that nothing should be written
with the
# HEAD method
I figured we had moved on to 2.3, but I wanted to make sure I wasn't
missing something before I changed the docs. I'm not sure if there was a
formal decision on this or everyone just assumed it was true. Perhaps a
pronoucement from Grisha to make it offical?
If python 2.2 support has been
OK then, good enough.
Next question. Should we bump the Apache version requirement as well.
Currently the docs state that Apache 2.0.40 or later is required. I
don't recall seeing anyone testing mod_python 3.2 on anything less than
apache 2.0.53. I don't know if there are any changes between
On Fri, 9 Dec 2005, Jim Gallacher wrote:
Next question. Should we bump the Apache version requirement as well.
Currently the docs state that Apache 2.0.40 or later is required. I
don't recall seeing anyone testing mod_python 3.2 on anything less than
apache 2.0.53. I don't know
Here's one that passes all the tests, and is 2x as fast as the 'current'
and 'new' implementations on random binary data. I haven't been able to
generate data where the 'mike' version is slower:
def read_to_boundary(self, req, boundary, file, readBlockSize=65536):
prevline =
Thanks for that improvement, don't like its complexity though. I'm
testing mikes version with my set of files I will all let you know
how it goes.
BTW, the line that reads last_bound = boundary + '--' so we save 4
CPU cycles there :)
The next test that I will run this against will be
Inspired by Mike's changes I made some changes the new version to
improve performance while keeping readability:
def read_to_boundary_new(self, req, boundary, file, readBlockSize):
previous_delimiter = ''
bound_length = len(boundary)
while 1:
line =
Sorry for all this emails, but my system depends 100% on mod_python
specially file uploading. :)
On Nov 7, 2005, at 2:04 PM, Jim Gallacher wrote:
Alexis Marrero wrote:
Jim,
Nicolas,
Thanks for sending the function that creates the test file.
However I ran it to create the test file, and
Alexis Marrero wrote:
Sorry for all this emails,
No worries. It's a bug that needs to be fixed, so your work will benefit
everyone. :)
Jim
, is this for your new read_to_boundary or the one in
3.2? If it's for yours then the MD5 sum *should* be the same, since
that's what you fixed. :)
Did you call it with the same block size as you are using in your
code? The '\r' character must appear in the file right at the
readBlockSize boundary.
ie
, and after uploading
the file the MD5 still the same.
Just to clarify, is this for your new read_to_boundary or the
one in 3.2? If it's for yours then the MD5 sum *should* be the
same, since that's what you fixed. :)
Did you call it with the same block size as you are using in
your
What i don't like at all in this implementation is the large amount of
memcpy operations.
1. line.strip()
2. line[:-x]
3. previous_delimiter + ...
The average pass will perform between two and three memcopy operations
on the read block.
Suggestion: Loose the strip() call - it serves no
/2005-March/017756.html
http://www.modpython.org/pipermail/mod_python/2005-November/019460.html
This triggered couple of changes in mod_python 3.2 Beta which reads as
follows:
33 # Fixes memory error when upload large files such as 700+MB ISOs.
34 readBlockSize = 65368
35
*...*
225
Hi guys,
In the pure if it ain't tested, it ain't fixed fashion, I've added a
unit test for file upload to the test suite. It uploads a randomly
generated 1 MB file to the server, and check that the MD5 digest
returned by the server is correct. I could not reproduce Alexis' bug
report this way,
OK, it looks like Alexis' fix solves the problem with ugh.pdf without
breaking the other unit tests. So I think we can safely integrate his
patch. Shall I do it ?
Regards,
Nicolas2005/11/6, Nicolas Lehuen [EMAIL PROTECTED]:
Hi guys,
In the pure if it ain't tested, it ain't fixed fashion, I've
Nicolas,Not that I'm the one to give permission whether to integrate things or not, but just to let you know I don't even have svn installed so I won't do it. At least not for a while...BTW, if there are some cherrypy developers in this mailing list, the CherryPy function that handles file uploads
I've been spending some quality time with hexedit, vim and a little bit
of python. I can now generate a file which can be used in the unit test.
The problem seems to occur when a '\r' character is right at
readBlockSize boundary, which is 65368 in the current mod_python.util.
I have not yet
Gregory (Grisha) Trubetskoy wrote:
So I guess this means we roll and vote on a 3.2.5b?
As much as it pains me to say it, but yes, this is a must fixm so it's
on to 3.2.5b.
I think we need to do some more extensive testing on Alexis's fix before
we roll 3.2.5b. His read_to_boundary is
with. Users will simply need to ensure that any module with function objects or
class objects in them isn't imported using the mod_python importing mechanism,
but that standard import is used.
Pickling/unpickling top-level functions defined in published module no
longer works in mod_python 3.2
the compile
problems
is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h the
typedef
for
apr_thread_mutex_t is wrapped by #if APR_HAS_THREADS
/
#endif.
Looking
problems
is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h
the
typedef
for
apr_thread_mutex_t is wrapped by #if
APR_HAS_THREADS /
#endif.
Looking at the apache source in
srclib/apr/locks/unix/thread_mutex.c,
everything is also enclosed by #if
APR_HAS_THREADS
(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile
problems
is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h the
typedef
WITH_THREAD
+
apr_thread_mutex_create(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile
problems
is new
for 3.2.
I also notice
+
apr_thread_mutex_create(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile
problems
is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h the
typedef
(); #endifSo it would seem that the code causing the compile problems is new for 3.2.
I also notice that in apr_arch_thread_mutex.h the typedef forapr_thread_mutex_t is wrapped by #if APR_HAS_THREADS / #endif.Looking at the apache source in srclib/apr/locks/unix/thread_mutex.c,
everything is also
(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile problems is new
for 3.2.
I also notice
,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile problems
is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h the typedef
for
apr_thread_mutex_t is wrapped
WITH_THREAD
+ apr_thread_mutex_create(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */ PyEval_InitThreads(); #endif
So it would seem that the code causing the compile problems is new for
3.2. I also notice that in apr_arch_thread_mutex.h the typedef
is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h the
typedef
for
apr_thread_mutex_t is wrapped by #if APR_HAS_THREADS /
#endif.
Looking at the apache source in
srclib/apr/locks/unix/thread_mutex.c,
everything is also enclosed by #if APR_HAS_THREADS /
#endif.
eg
*/ Py_Initialize();
#ifdef WITH_THREAD +
apr_thread_mutex_create(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p); /* create and acquire the interpreter lock */
PyEval_InitThreads(); #endif So it would seem that the code causing the compile
problems is new for
3.2. I also notice
the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile
problems
is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h the
typedef
for
apr_thread_mutex_t is wrapped by #if APR_HAS_THREADS /
#endif.
Looking at the apache
; + /* initialze the interpreter */ Py_Initialize();
#ifdef WITH_THREAD + apr_thread_mutex_create(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p); /* create and acquire the interpreter lock */ PyEval_InitThreads();
#endif So it would seem that the code causing the compile problems is new for 3.2
+
apr_thread_mutex_create(interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p);
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
So it would seem that the code causing the compile problems is new
for 3.2.
I also notice that in apr_arch_thread_mutex.h
:-) Graham - don't you have FreeBSD access somewhere?
If Graham can't help out maybe we could recruit a volunteer on the
mod_python
list?
On the versioning discussion - I don't like 4.0, I think 3.3 should be the
next version after 3.2.x. As far as even/odd stable/unstable - the Linux
kernel
into 3.2. This would depend though on how many
more beta snapshots we think we might go through.
Graham
2005/9/8, Jorey Bump [EMAIL PROTECTED]:
Jim Gallacher wrote:
Nicolas Lehuen wrote:
Well, why not keep our plan of releasing 3.2 ASAP and save this
problem for a later 3.2.x as a bug fix ?
Making subsequent bug-fix releases should be fast and easy. We cannot
afford to repeat the long
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
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 test
tarbal?
Thanks!
Grisha
On Thu, 1 Sep 2005, Graham Dumpleton wrote:
Well, if I've understood Jim's mail, apart from the new MODPYTHON-77, we're all set.
Regards,
Nicolas2005/9/6, Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]:
I've been away this weekend - just got back, but I'm too busy to try toread all the multiple-interpreter related comments. I guess my
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
test tarbal?
I've also been away for the
On Tue, 6 Sep 2005, Jim Gallacher wrote:
As Graham stated on the weekend, the use of thread states can be very
tricky. I think we should proceed with the 3.2.1b without the fix. That way
we can take the time to make sure we understand the issues and fix it in 3.3.
If that seems reasonable,
Or speaking in diff (not tested):
--- setup.py.in.orig2005-09-01 11:42:09.082202944 -0400
+++ setup.py.in 2005-09-01 11:44:35.969872624 -0400
@@ -140,18 +140,24 @@
# this is a hack to prevent build_ext from trying to append
initmod_python to the export symbols
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.
/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 enough problem to hold up the 3.2 release?
Regards,
Jim
Graham Dumpleton wrote:
In 3.2
/MODPYTHON-75 http://issues.apache.org/jira/browse/MODPYTHON-60 Boyan's patch detailed in MODPYTHON-75 seems to fix both of these.
Fix is ready to commit.5. http://issues.apache.org/jira/browse/MODPYTHON-72Fix still required.6. Publisher bug in 3.2 BETA, detailed by Graham in python-dev message
posted 2005
://issues.apache.org/jira/browse/MODPYTHON-75
http://issues.apache.org/jira/browse/MODPYTHON-60
Boyan's patch detailed in MODPYTHON-75 seems to fix both of these.
Fix is ready to commit.
5. http://issues.apache.org/jira/browse/MODPYTHON-72
Fix still required.
6. Publisher bug in 3.2 BETA
Nicolas Lehuen wrote:
Hi Jim,
The fix for MODPYTHON-72
http://issues.apache.org/jira/browse/MODPYTHON-72 should be easy,
unfortunately I'm quite busy right now, since my first daughter was born
three days ago...
Congratulations Nicolas!
I'll do my best to have a look at it, but if
/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 enough problem to hold up the 3.2 release?
Regards,
Jim
Graham Dumpleton wrote:
In 3.2
On Thu, 25 Aug 2005, Jim Gallacher wrote:
I think we should aim for the second beta release in the next couple of days.
I have a few questions and a list of outstanding issues.
Name of tarball: mod_python-3.2.1b.tgz?
yep, 3.2.1b
Also, I assume a new branch called tags/release-3.2.1-BETA
On Tue, 16 Aug 2005, Jim Gallacher wrote:
What is the correct name for the tarball?
mod_python-3.2.0-b.tgz, mod_python-3.2.0-BETA.tgz or something else?
I like mod_python-3.2.0b and the tarball would be mod_python-3.2.0b.tgz
Grisha
/MODPYTHON-12
The patch for this one would have eliminated the last workaround
that I keep having to propagate in my code, even though the
minimum requirement for my code was going to be to have 3.2.
Guess I'll have to go back and put the workaround in again until
3.2.X. :-(
But you have an opportunity
I think the best thing to do is just to go ahead and tag and a create a
tarball. Whether everyone was ready will become apparent during the
testing/voting.
Grisha
On Mon, 15 Aug 2005, Jim Gallacher wrote:
Are we on track to release a 3.2.0beta tarball today?
Regards,
Jim
Gregory (Grisha) Trubetskoy wrote:
On Wed, 10 Aug 2005, Jim Gallacher wrote:
Compilation fails with the following:
requestobject.c: In function 'request_tp_dealloc':
requestobject.c:1482: warning: implicit declaration of function
'request_tp_clear'
This looks like a bug - I guess GCC 3
[EMAIL PROTECTED]:
Sorry, getting a bit overwhelmed with all these rapid changes in stateof things as bit busy today. Will probably will only know what is goingon 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
[ http://issues.apache.org/jira/browse/MODPYTHON-65?page=all ]
Nicolas Lehuen resolved MODPYTHON-65:
-
Fix Version: 3.2.0
Resolution: Fixed
3.2 working version will not install on Mac OS X (10.3.7
Nicolas Lehuen wrote:
MODPYTHON-34 has been fixed in the current version of the publisher,
with the new importing system. As I've written before, I can roll back
the part regarding the import system if you really want that, all the
while maintaining the fix for MODPYTHON-34.
I haven't had
range of usage patterns people could have of the
publisher, but anyway, it's better than nothing.
So, I think we should move forward on the 3.2 release. The new
publisher code is meant to make it work better, not worse, while
retaining the compatibility with the current code. It's not a new
tests
reflect the whole range of usage patterns people could have of the
publisher, but anyway, it's better than nothing.
So, I think we should move forward on the 3.2 release.
+1
The new publisher
code is meant to make it work better, not worse, while retaining the
compatibility
Just thought I'd ask if we're making any progress towards a 3.2 tarball to
test. No pressure, just curious :-)
Grisha
of them should be included in the 3.2 release ?
My inclanation is to just release whatever we have, and mark it as a
beta release. The last true release was 3.1.3 in Feb 2004, which makes
it 18 months (if my math is correct)
Grisha
I've either commited fixes or have fixes ready for 6 or 8
Gregory (Grisha) Trubetskoy wrote:
On Thu, 28 Jul 2005, Jim Gallacher wrote:
I've either commited fixes or have fixes ready for 6 or 8 of those
issues. Also there some that don't apply to 3.2 (eg website or mailing
list issues). Must run right now but will make a list this evening of
issues
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
3.2 working version will not install on Mac OS X (10.3.7)
-
Key: MODPYTHON-65
URL: http://issues.apache.org/jira/browse/MODPYTHON-65
Project: mod_python
Type: Bug
Components: core
Versions: 3.2.0
,
description=Apache/Python Integration,
3.2 working version will not install on Mac OS X (10.3.7)
-
Key: MODPYTHON-65
URL: http://issues.apache.org/jira/browse/MODPYTHON-65
Project: mod_python
70 matches
Mail list logo
