mod_python 3.2.x / FreeBSD 6.0 / Python 2.4.3 +1

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

[jira] 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-81?page=all ] Graham Dumpleton closed MODPYTHON-81: - > Pickling/unpickling top-level functions defined in published module no > longer works in mod_pyth

[jira] Resolved: (MODPYTHON-81) Pickling/unpickling top-level functions defined in published module no longer works in mod_python 3.2

> longer works in mod_python 3.2 > -- > > Key: MODPYTHON-81 > URL: http://issues.apache.org/jira/browse/MODPYTHON-81 > Project: mod_python > Type:

[jira] Closed: (MODPYTHON-65) 3.2 working version will not install on Mac OS X (10.3.7)

[ 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) > - > >

Re: 3.2.x branch

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 su

3.2.x branch

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 announceme

mod_python.publisher, HEAD and 3.2.

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 # H

Re: Does 3.2 still support python 2.2?

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 if

Re: Does 3.2 still support python 2.2?

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 chang

Re: Does 3.2 still support python 2.2?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://article.gmane.org/gmane.comp.apache.mod-python.devel/865 Jim Gallacher wrote: | 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 o

Re: Does 3.2 still support python 2.2?

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 drop

Re: Does 3.2 still support python 2.2?

I'm pretty sure we've had a few discussions about being able to use certain functions and modules because they became available in 2.3, and that's what mod_python was going to require. Like the bsddb database version for your session code, for example. Nick Jim Gallacher wrote: From the 3.

Does 3.2 still support python 2.2?

From the 3.2.5b doc: (http://www.modpython.org/live/mod_python-3.2.5b/doc-html/inst-prerequisites.html) 2.1 Prerequisites * Python 2.2.1 or later. Earlier versions of Python will not work. Is this still true or have we dropped support for python < 2.3? Has anybody tested using python 2.2

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

OK, this time I think the file upload problem is solved for good. I've checked-in Alexis's code, with comments. Then I've done a quick rewrite of the multipart/form-data parser found in FieldStorage.__init__ and read_to_boundary so that it uses a regexp for the boundary checks, with the hope that i

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

Guys, next time please use the JIRA bug tracking application available at : http://nagoya.apache.org/jira/browse/MODPYTHON Especially this bug report : http://issues.apache.org/jira/browse/MODPYTHON-40 I'm currently re-reading the whole thread and trying to make sense of all the test files and

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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 = req.readline(readBlockS

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

Mike Looijmans wrote: I've attached a modified upload_test_harness.py that includes the new and current, also the 'org' version (as in 3.1 release) and the 'mike' version. Nice changes, Mike. I started to get confused by the names of the various read_to_boundary_* functions, so I've made a s

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

Alexis Marrero wrote: The next test that I will run this against will be with an obscene amount of data for which this improvement helps a lot! The dumb thing is the checking for boundaries. I'm using http "chunked" encoding to access a raw TAPE device through HTTP with python (it GETs or PO

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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 = "" last_bou

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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 purpose

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

in the client is the same one as in the server. Do you have different results? Let me know. Regards, /amn On Nov 7, 2005, at 2:11 PM, Jim Gallacher wrote: Jim Gallacher wrote: Alexis Marrero wrote: Jim, Thanks for sending the function that creates the test file. However I ran it to c

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

rero wrote: Jim, Thanks for sending the function that creates the test file. However I ran it to create the test file, 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 *s

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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 a

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

Jim Gallacher wrote: Alexis Marrero wrote: Jim, Thanks for sending the function that creates the test file. However I ran it to create the test file, 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'

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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 after uploading the file the MD5 still the same. Did you call it with the same block size as you are using in your code? The '\r' character must app

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

Nicolas Lehuen wrote: Well, I've re-read the previous code and it looks like it does almost the same thing except it is bugged :). CherryPy's implementation is almost the same except it ought to work. Jim, I've integrated your tricky file into the unit test. Alexis' version passes all tests,

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

Well, I've re-read the previous code and it looks like it does almost the same thing except it is bugged :). CherryPy's implementation is almost the same except it ought to work. Jim, I've integrated your tricky file into the unit test. Alexis' version passes all tests, whereas the current version

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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 much

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

So I guess this means we roll and vote on a 3.2.5b? Grisah On Sun, 6 Nov 2005, Nicolas Lehuen wrote: 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, Nicolas

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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 t

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

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,

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

I don't have a function that creates the files but the I can point you to a file that has the problem, ironically is "Unix Haters Handbook" :) Well, at least is not the Python HH http://research.microsoft.com/~daniel/uhh-download.html It's MD5 is 9e8c42be55aac825e7a34d448044d0fe. I don't

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

Alexis, I wanted to add that I'm testing your code. Alexis Marrero wrote: Let me know any comments on it and if you test it and fails please also let me know. I don't have subversion account neither I don't know how to use it thus this email. You don't need an account to use subversion ano

Re: mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

n/2005-March/017754.html http://www.modpython.org/pipermail/mod_python/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 fil

mod_python.util.StorageField.read_to_boundary has problems in 3.1 and 3.2

odpython.org/pipermail/mod_python/2005-March/017754.htmlhttp://www.modpython.org/pipermail/mod_python/2005-March/017756.htmlhttp://www.modpython.org/pipermail/mod_python/2005-November/019460.htmlThis triggered couple of changes in mod_python 3.2 Beta which reads as follows:    33  # Fixes mem

[jira] Updated: (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-81?page=all ] Nicolas Lehuen updated MODPYTHON-81: Component: importer > Pickling/unpickling top-level functions defined in published module no > longer works in mod_pyth

[jira] Commented: (MODPYTHON-81) Pickling/unpickling top-level functions defined in published module no longer works in mod_python 3.2

ived 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 >

[jira] Created: (MODPYTHON-81) Pickling/unpickling top-level functions defined in published module no longer works in mod_python 3.2

Pickling/unpickling top-level functions defined in published module no longer works in mod_python 3.2 -- Key: MODPYTHON-81 URL: http://issues.apache.org/jira/browse/MODPYTHON-81

Name suggestions svn 3.2 stable branch

Gregory (Grisha) Trubetskoy wrote: On Thu, 22 Sep 2005, Jim Gallacher wrote: On another note, if we are starting to roll with new features for 3.3 I would suggest we need to immediately create a new svn branch for 3.2 bugfixes. Yes Any preference for a branch name? Some suggestions

Re: Getting ready for 3.2 beta 2

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

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

(); #endif ... snip ... @@ -149,6 +158,7 @@ #ifdef WITH_THREAD PyEval_ReleaseLock(); + apr_thread_mutex_unlock(interpreters_lock); #endif ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

f WITH_THREAD + apr_thread_mutex_lock(interpreters_lock); PyEval_AcquireLock(); #endif ... snip ... @@ -149,6 +158,7 @@ #ifdef WITH_THREAD PyEval_ReleaseLock(); + apr_thread_mutex_unlock(interpreters_lock); #endif ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if n

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

lock(interpreters_lock); PyEval_AcquireLock(); #endif ... snip ... @@ -149,6 +158,7 @@ #ifdef WITH_THREAD PyEval_ReleaseLock(); + apr_thread_mutex_unlock(interpreters_lock); #endif ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

dif ... snip ... @@ -149,6 +158,7 @@ #ifdef WITH_THREAD PyEval_ReleaseLock(); + apr_thread_mutex_unlock(interpreters_lock); #endif ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()) { - + initia

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

f necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()) { - + initialized = 1; + /* initialze the interpreter */ Py_Initialize(); #ifdef WITH_THREAD + apr_thread_mutex_create(&interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p); /* create and a

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

t;>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Debian sid with apache2.0.54 mpm-prefork, APR_HAS_

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

ITH_THREAD PyEval_ReleaseLock(); + apr_thread_mutex_unlock(interpreters_lock); #endif ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()) { - + initialized = 1; + /* initialze the inte

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

;>>> >>>>>>>>>>>>> On Debian sid with apache2.0.54 mpm-prefork, APR_HAS_THREAD >>>>>>>>>>>>> == >>>>>>>>>>>> >>>>>>>>>>>> >>>>&

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

ters_lock); #endif ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()) { - + initialized = 1; + /* initialze the interpreter */ Py_Initialize(); #ifdef WITH_THREAD + apr_

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

I see Grisha has posted another patch which I will test next. It's taking longer to test these things than I thought because of the slowness of qemu combined with my stumbling around in FreeBSD. Please be patient. :) In the mean time I've tested with the LD_PRELOAD and PYTHON_WITH_THREAD_SUPP

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

itialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()) { - + initialized = 1; + /* initialze the interpreter */ Py_Initialize(); #ifdef WITH_THREAD + apr_thread_mutex_create(&interpreters_lock,APR_THREAD_MUTEX_UNN

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

snip ... @@ -149,6 +158,7 @@ #ifdef WITH_THREAD PyEval_ReleaseLock(); + apr_thread_mutex_unlock(interpreters_lock); #endif ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

MODPYTHON-2>>>>>>>>>> < http://issues.apache.org/jira/browse/MODPYTHON-2>.>>>>>>>>>>>>>>>>>>>> The problem is not in the patch, but rather in the fact >>>>>>>>>>>>>>>> that>>&

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

- + initialized = 1; + /* 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 c

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

> issue, feel free to tell us :). >>>>>>>>>>>>>>>> Regards,>>>>>>>> Nicolas>>>>>>>>>>>>>>>> 2005/9/10, Jim Gallacher < [EMAIL PROTECTED]>>>>>> [EMAIL PROTECTED]&g

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

lize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()) { - + initialized = 1; + /* initialze the interpreter */ Py_Initialize(); #ifdef WITH_THREAD + apr_thread_mutex_create(&interpreters_lock,APR_THREAD_MUTEX_UNNESTED

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

if ... snip ... @@ -490,13 +506,15 @@ } /* initialize global Python interpreter if necessary */ - if (! Py_IsInitialized()) + if (initialized == 0 || !Py_IsInitialized()) { - + initialized = 1; + /* initialze the interpreter */ Py_Initialize(); #ifdef WITH_THREAD + apr_thread_mutex_create(

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

gt;>>>  >>>  `apr_thread_mutex_unlock'>>>>  >>>  mod_python.c: In function `python_init':>>>>  >>>  mod_python.c:517: warning: implicit declaration of function>>>>  >>>  `apr_thread_mutex_crea

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

_AcquireLock(); >>> #endif >>> >>> ... snip ... >>> >>> @@ -149,6 +158,7 @@ >>> >>> #ifdef WITH_THREAD >>> PyEval_ReleaseLock(); >>> +apr_thread_mutex_unlock(

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

D >>> +apr_thread_mutex_lock(interpreters_lock); >>> PyEval_AcquireLock(); >>> #endif >>> >>> ... snip ... >>> >>> @@ -149,6 +158,7 @@ >>> >>> #ifdef WITH_TH

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

2005/9/12, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>: On Mon, 12 Sep 2005, Jim Gallacher wrote:> *** Warning: Linking the shared library mod_python.la against the> *** static library /usr/local/lib/python2.4/config/libpython2.4.a is not> portable! I think this was always there and its pretty

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

lock(interpreters_lock); >>> PyEval_AcquireLock(); >>> #endif >>> >>> ... snip ... >>> >>> @@ -149,6 +158,7 @@ >>> >>> #ifdef WITH_THREAD >>> PyEval_Rele

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

.. snip ... >>> >>> @@ -149,6 +158,7 @@ >>> >>> #ifdef WITH_THREAD >>> PyEval_ReleaseLock(); >>> +apr_thread_mutex_unlock(interpreters_lock); >>> #endif >>> >>> ...

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

28,15 @@>>>   name = MAIN_INTERPRETER;>>>>>>   #ifdef WITH_THREAD>>>  +apr_thread_mutex_lock(interpreters_lock); >>>   PyEval_AcquireLock();>>>   #endif>>>>>>  ... snip ...>>>>>>  @@ -149,6 +

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

|| !Py_IsInitialized()) { - +initialized = 1; + /* initialze the interpreter */ Py_Initialize(); #ifdef WITH_THREAD + apr_thread_mutex_create(&interpreters_lock,APR_THREAD_MUTEX_UNNESTED,p); /* create and acquire the interpreter

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

ter */ 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

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

ized()) > +if (initialized == 0 || !Py_IsInitialized())>   {> -> +initialized = 1;> +>   /* initialze the interpreter */>   Py_Initialize();> >   #ifdef WITH_THREAD> +> apr_thread_mutex_create(&interpreters_lock,APR_THREAD_

Re: FreeBSD compile problem (was Getting ready for 3.2 beta 2)

Python interpreter if necessary */> -if (! Py_IsInitialized()) > +if (initialized == 0 || !Py_IsInitialized())>   {> -> +initialized = 1;> +>   /* initialze the interpreter */>   Py_Initialize();> >   #ifdef WITH_THREAD> +> apr_thread_mutex

Re: Getting ready for 3.2 beta 2

;> > >>>>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? > >>> > >>>If Graham can't help out maybe we could recruit a volunteer o

Re: Getting ready for 3.2 beta 2

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? If Graham can't help out maybe we could recruit a volunteer on the mod_python list? On the versioning discussion - I don

Re: Getting ready for 3.2 beta 2

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 featu

Re: Getting ready for 3.2 beta 2

Nicolas Lehuen wrote: 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

Re: Getting ready for 3.2 beta 2

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 release

Re: Getting ready for 3.2 beta 2

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 hiatus between 3.1.3 and 3.2, with a long period

Re: Getting ready for 3.2 beta 2

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 hiatus between 3.1.3 and 3.2, with a long period of time without any

Re: Getting ready for 3.2 beta 2

On Thu, 8 Sep 2005, Nicolas Lehuen wrote: Releasing often may need a bit of work on the web site side, however. with respect to modpython.org, no, not at all. with httpd.apache.org - it's a little bit of work, but not more than 15 minutes. I feel that updating the web site is the current

Re: Getting ready for 3.2 beta 2

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 hiatus between 3.1.3 and 3.2, with a long period of time without any official bug fix. I agree

Re: Getting ready for 3.2 beta 2

think that this change to support use of extensions using the simplified GIL interface should be incorporated into 3.2. This would depend though on how many more beta snapshots we think we might go through. Graham

Re: Getting ready for 3.2 beta 2

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,

Re: Getting ready for 3.2 beta 2

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

Re: Getting ready for 3.2 beta 2

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 ques

Re: Getting ready for 3.2 beta 2

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: N

Re: Getting ready for 3.2 beta 2

Well I for one am happy woth MODPYTHON-73, I've integrated Graham's patch and made unit test to check if everything was OK. Graham should be happy too :). Regards, Nicolas2005/9/1, Jim Gallacher <[EMAIL PROTECTED]>: I've tested this patch and checked it into svn. Should probably betested for winbu

Re: Getting ready for 3.2 beta 2

I've tested this patch and checked it into svn. Should probably be tested for winbuild and MacOS X. I think we are good to go if Graham and Nicolas are happy with their MODPYTHON-73 changes. Jim Gregory (Grisha) Trubetskoy wrote: Or speaking in diff (not tested): --- setup.py.in.orig2

Re: Getting ready for 3.2 beta 2

On Wed, 31 Aug 2005, Jim Gallacher wrote: 3. Eliminate creation of mod_python_so.so in non-windows environments. Fix is ready to commit. Not Done. I decided to defer this for reasons I won't go into just now. It is not a show stopper anyway. Isn't the fix basically just placing the Mod

Re: Getting ready for 3.2 beta 2

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 self.expor

Re: Getting ready for 3.2 beta 2

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),

Re: Getting ready for 3.2 beta 2

apache.org/jira/browse/MODPYTHON-72 Fix still required. Done 6. Publisher bug in 3.2 BETA, detailed by Graham in python-dev message posted 2005-08-21. Fix still required. Done (fix for item 5 fixed this as well). Regards, Jim

Re: Getting ready for 3.2 beta 2

It's my first child (but the second for my wife), and her name is Violette. And I totally crazy of her ! The problem for you guys is that I've been preparing my house for her coming back (she came a bit earlier than expected so I had to hurry things a little bit), so I had no time to work on mod_py

Re: Publisher bug in 3.2 BETA.

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

Re: Getting ready for 3.2 beta 2

On Fri, 26 Aug 2005, Nicolas Lehuen wrote: unfortunately I'm quite busy right now, since my first daughter was born three days ago... Wow! Congratulations Is this a first child? Does she have a name? Anyway, scratch that word "unfortunately", you didn't mean it! :-) Grisha

Re: Getting ready for 3.2 beta 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 wi

Re: Publisher bug in 3.2 BETA.

r/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 enough problem to hold up the 3.2 rel

Re: Getting ready for 3.2 beta 2

Nicolas Lehuen wrote: Hi Jim, The fix for 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 someo

Getting ready for 3.2 beta 2

://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

Re: Getting ready for 3.2 beta 2

ssues.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-72Fix still required.6. Publisher bug in 3.2 BETA, de

  1   2   >