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)

Alright, cool. So I guess we're ready to roll the next tarfile now. Grisha On Tue, 13 Sep 2005, Nicolas Lehuen wrote: I'm sure it is required, even after fixing the S in APR_HAS_THREADS I tried with and without the PyEval_AcquireLock code and the latter works while the former doesn't. I don'

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

Good job - I've tested it and it works on FreeBSD. Just one last thing I wanted to confirm - are you sure that PyEval_AcquireLock is required, or was this a sideffect of the missing 'S'? I just want to make sure we're not doing double locking where it's not needed. Grisha On Tue, 13 Sep 200

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

Gregory (Grisha) Trubetskoy wrote: Done. All tests pass on my FreeBSD box. Nicolas - can you test Win32, I'm not 100% sure if the change to test.py I made will work. Good news. If the changes can be checked in and Nicolas can give a +1 on the Windows test then I'll be able to generate the ne

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

Done. All tests pass on my FreeBSD box. Nicolas - can you test Win32, I'm not 100% sure if the change to test.py I made will work. Grisha On Tue, 13 Sep 2005, Nicolas Lehuen wrote: Yes, now I remember I had to comment this line out because it broke something on Win32. Go ahead, uncomment i

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

I'd keep the patch nonetheless - I think this is how it should be. Grisha On Mon, 12 Sep 2005, Jim Gallacher wrote: -1 for this patch. Actually, the patch itself is fine - it just doesn't fix the problem. The unit tests are still failings as per my previous messages. ie the following is gett

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

OK, I found the problem. The LockFile line is commented out in test.py which causes Apache to try to create the lock in the default location in /var/run. http://svn.apache.org/viewcvs.cgi/httpd/mod_python/trunk/test/test.py?rev=125771&r1=106619&r2=125771 So the question is - can we just put

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

3.1.4 compiles and tests OK on my FreeBSD box (given that all versions of mod_python up to 3.1 were primarily developed on FreeBSD, it better ;) ). We just need figure out what causes the "No such file" and we'll be good to go. Grisha On Tue, 13 Sep 2005, Nicolas Lehuen wrote: Jim, do yo

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

Nicolas Lehuen wrote: Jim, do you manage to build and test the 3.1.4 version on your setup ? This looks like a permission problem, not something related to our current problem. I haven't tried 3.1.4. And I could also try the tests as root, which would eliminate any permission problems. I have

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

-1 for this patch. Actually, the patch itself is fine - it just doesn't fix the problem. The unit tests are still failings as per my previous messages. ie the following is getting logged in test/logs/error_log: [Mon Sep 12 19:49:33 2005] [emerg] (2)No such file or directory: Couldn't create ac

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)

Here's a patch (this is against 3.1.2b). Untested. This replaces GIL with with the APR lock. --- src/mod_python.c.orig Mon Sep 12 16:42:28 2005 +++ src/mod_python.cMon Sep 12 17:32:26 2005 @@ -31,7 +31,9 @@ * (In a Python dictionary) */ static PyObject * interpreters = NULL; +#if

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

Yep, this is getting a little hairy, but nothing we couldn't handle :-) I did a little more research. Basically, this started with Graham's patch that addressed a problem with modules being reimported (or something). From Graham's message: The basic problem revolves around the Python dict

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

Duh, this is becoming difficult :) I was thinking that if APR_HAS_THREADS was 0, then Apache was forcibly ran in prefork mode, so there was no need for thread safety at all, given the fact that mod_python would only run one interpreter thread. So if WITH_THREAD was not defined, ORAPR_HAS_THREADS w

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

I'm not sure I understand this, perhaps someone could write a message to the list explaining what we're doing here so there is a record. Sorry if I'm being slow-headed here. To me it seems that when you use thread-related calls from Python, you wrap those in Python defines (WITH_THREAD) and

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

Well, it depends : #if(defined(WITH_THREAD) && APR_HAS_THREADS)     #define MOD_PYTHON_WITH_THREAD_SUPPORT 1 #else     #define MOD_PYTHON_WITH_THREAD_SUPPORT 0 #endif It's not only a matter of Python supporting threads, we must also have a thread-enabled APR. So that's the reason for the

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

Gregory (Grisha) Trubetskoy wrote: Shouldn't that be PYTHON_WITH_THREAD rather than MOD_PYTHON_WITH_THREAD? I understand it to mean that we want the thread handling code compiled into mod_python. Compiling and testing right now. Jim On Mon, 12 Sep 2005, Nicolas Lehuen wrote: I've chec

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

Shouldn't that be PYTHON_WITH_THREAD rather than MOD_PYTHON_WITH_THREAD? Grisha On Mon, 12 Sep 2005, Nicolas Lehuen wrote: I've checked in a changeset wherein I define MOD_PYTHON_WITH_THREAD_SUPPORT and use it everywhere WITH_THREAD was previously used. This should do the trick ! Now if someo

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

I've checked in a changeset wherein I define MOD_PYTHON_WITH_THREAD_SUPPORT and use it everywhere WITH_THREAD was previously used. This should do the trick ! Now if someone (like Jim) can give us his +1, that would be great. Regards, Nicolas2005/9/12, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]

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

Just wanted to add to this message that if Jim's version runs and tests with the trick below (envvars is executed prior to apache start, but I don't think the tests use it, so you'll probably just have to set this var in the shell in which the tests are run), then this would be a solution for

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

OK, found it. This should work on FreeBSD where Python is threaded and Apache is not. [snip] And, if you built apache without thread support, you may need to add the following lines to $PREFIX/sbin/envvars: LD_PRELOAD=/usr/lib/libc_r.so export LD_PRELOAD [snip] On Mon, 12 Sep 2005, Gr

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)

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 harmless. On qemu: Syntax error on line 44 of /usr/hom

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

Nicolas Lehuen wrote: OK, so on a non-threaded Apache, we can suppose we will be using the prefork MPM, so we don't need any code to support threading in mod_python, then, right ? Makes sense to me. In this case instead of testing for WITH_THREAD in mod_python.c : #ifdef WITH_THREAD maybe

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

OK, so on a non-threaded Apache, we can suppose we will be using the prefork MPM, so we don't need any code to support threading in mod_python, then, right ? In this case instead of testing for WITH_THREAD in mod_python.c : #ifdef WITH_THREAD maybe we could test for WITH_THREAD and APR_HAS_THREAD

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

FYI, I found the following note in the INSTALL file in the apache source: * If you are building on FreeBSD, be aware that threads will be disabled and the prefork MPM will be used by default, as threads do not work well with Apache on FreeBSD. If you wish to try a threaded Apache o

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

Nicolas Lehuen wrote: OK, I've checked in a version that compiles both on at least Win32 and FreeBSD. I'm just testing if APR_HAS_THREAD is defined and only include the apr_thread_mutex_lock and unlock calls if it is defined. Compiles a passes unit tests on Linux Debian sid with mpm-prefork.

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

OK, I've checked in a version that compiles both on at least Win32 and FreeBSD. I'm just testing if APR_HAS_THREAD is defined and only include the apr_thread_mutex_lock and unlock calls if it is defined. Now, on minotaur, APR_HAS_THREAD is defined as 0. Does this mean that Apache is not configured

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

Yes, this new code is something I commited on the 29/12/2004 (I used the "blame" function of TortoiseSVN for that). It was a patch by Graham to fix MODPYTHON-2. The problem is not in the patch, but rather in the fact that APR seems configured without the thread support while Python is configured w

Re: Getting ready for 3.2 beta 2

I've tried to build 3.1.4 from the tarball on minotaur and of course it works. Could it be possible that the recent changes in the configure script cause the problem ? Regards, Nicolas 2005/9/10, Jim Gallacher <[EMAIL PROTECTED]>: > I thought I'd it a shot on minotaur as well. > > Poking around

Re: Getting ready for 3.2 beta 2

I thought I'd it a shot on minotaur as well. Poking around a bit reveals that the default apache is indeed 1.3. It looks like there might be a viable apache2 hiding in /usr/local/apache2-install/www.apache.org/current. eg ./configure --with-apxs=/usr/local/apache2-install/www.apache.org/curr

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 features

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 afford t

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 releases should be fast and easy. We cannot > >> afford to

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 of

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 offic

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 t

Re: Getting ready for 3.2 beta 2

Jim Gallacher wrote .. > Gregory (Grisha) Trubetskoy wrote: > > > > I've been away this weekend - just got back, but I'm too busy to try > to > > read all the multiple-interpreter related comments. I guess my question > > is - can someone provide a quick summary of how far we are from 3.2.1b > >

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

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. Jim Gallacher wrote: I think we should aim for the second beta release in the next couple of days. I have a few questions an

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

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? Also, I assume a new branch called tags/release-3.2.1-BETA will be created in subversion, correct? Outstanding issues:

Re: Getting ready for 3.2 beta 2

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... I'll do my best to have a look at it, but if someone feels like doing it, I'll understand. Regards, Nicolas2005/8/26, Jim Gallacher <[EMAIL PROTECTED]>: I th