Re: Developer Guidelines (was Re: More efficient FieldStorage, StringField and Field classes)
Ok, following Jim's advice, an having read his guide, I have so far: - Fetched the trunk version with anonymous SVN (no problem) I've already installed apache 2.0.55 and Python 2.4.1 on this Windows machine (the lazy way, with MSI packages). I've also installed the latest Cygwin (all default packages). However, I'm not getting anywhere in compiling mod_python. It requires the apxs tool which is apparently not part of any Apache windows distribution. So I grabbed the apache 2.0.55 source for windows, but the configure script is now stuck for over half an hour on: Configuring Apache Portable Runtime Utility library... checking for APR-util... reconfig configuring package in srclib/apr-util now Nothing appears to happen. Anyone here who can help me out getting this up and running on Windows XP? I can also use linux machines for compile and tests (I'm not root on any), but I do most development on this Windows system, so I need a windows executable anyway. PS: Haven't found any speling errors in your document... Jim Gallacher wrote: Mike Looijmans wrote: Inspired by our FieldStorage work with file uploads, I also made some implementation changes to Field and StringField in util.py. In essense, that will make things like using form['key'] multiple times much more efficient. Also, FieldStorage will return the same object if called twice. I'd like some feedback from the group on these changes, and also some directions on what I'd need to do to get them integrated in the mod_python beta. I have no experience whatsoever in contributing to open source projects. I think it's too late in the beta cycle to be rewriting code unless it's to fix a specific, critical bug. We really, really, *really* need to deliver 3.2 final, and I don't want to mess with working code at this point. The changes you are suggesting are likely more appropriate for 3.3, or possibly a 3.2 bugfix release. As far as contributing to mod_python, well, I think you already have the right idea: propose changes; discuss on python-dev; seek consensus; wait for your changes to be committed by myself or Nicolas. Bug fixes and code improvements are much more likely to be accepted than major new features. We want mod_python to be tightly focused on the core functionality of providing a python interface to apache. The fancy bells and whistles are best left to frameworks that utilize mod_python further up the application stack. For your specific changes, I would strongly suggest that you make your changes against the mod_python development branch, ie trunk. Also people are much more likely to test your changes if you submit a patch rather than offering a completely new file. This makes it easier to see what code is being changed and avoids problems with regressions. I've put together a Developer's Guide draft that I'd like to eventually see included in either the documentation or on the website. This document doesn't represent any offical position of the mod_python developers, but rather just what I see as best practices and some resources for contributors. Everyone should feel free to offer suggestions to improve this guide. The original is in svn at: http://svn.apache.org/repos/asf/httpd/mod_python/branches/jgallacher/docs/developers-guide.rst And no, I have not spell checked it yet. :) -- Mike Looijmans Philips Natlab / Topic Automation
Re: Developer Guidelines (was Re: More efficient FieldStorage, StringField and Field classes)
David Fraser wrote: See my other mail - basically you do cd dist set APACHESRC=c:\path\to\apache (where this is the Apache2 dir in a standard installation, now need for apache source) build_installer Okay, first I downloaded the .NET SDK. (Our internet connection is great here) Then I get: error: Python was built with version 7.1 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. I don't have a VS license - that would mean I have to build my own Python in order to get any further. Oh dear... I was wondering - since i won't be hackin' the C code (yet), would it be sufficient to just install the binary, and use the .py files as obtained from the SVN repository? The 3.2.5 beta seems to run just fine here. Cannot run the automated tests though, because of the issues mentioned above. -- Mike Looijmans Philips Natlab / Topic Automation
Re: Developer Guidelines (was Re: More efficient FieldStorage, StringField and Field classes)
Mike Looijmans wrote: David Fraser wrote: See my other mail - basically you do cd dist set APACHESRC=c:\path\to\apache (where this is the Apache2 dir in a standard installation, now need for apache source) build_installer Okay, first I downloaded the .NET SDK. (Our internet connection is great here) Then I get: error: Python was built with version 7.1 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. I don't have a VS license - that would mean I have to build my own Python in order to get any further. Oh dear... Strange, I have VS.NET 2003 installed here, and it doesn't give errors. I think I got mod_python compiling at one stage with mingw so that is the other route you could go... I was wondering - since i won't be hackin' the C code (yet), would it be sufficient to just install the binary, and use the .py files as obtained from the SVN repository? Yes you should be able to install the binary and run the tests from the repository (if you can get past the issues I had running them ...) The 3.2.5 beta seems to run just fine here. Cannot run the automated tests though, because of the issues mentioned above. Cheers David
Re: mod_python 3.2.5b available for testing
hehe - sorry about that, should be fixed now Grisha On Tue, 15 Nov 2005, David Fraser wrote: Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. The windows binary for python 2.3 is borked, and contains its own md5sum, being only 68 bytes long. This did raise the interesting thought of how easy it would be to create a file which contains its own md5sum, but aside from that, I think it should be reuploaded :-) David
Re: mod_python 3.2.5b available for testing
+1 MacOSX 10.4.3, gcc 4.0.0 (apple), Python-2.4.2, Apache-2.0.55 cheers, Ron On Mon, 14 Nov 2005, Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. This release is similar to 3.2.4b but fixes a couple of minor issues - MODPYTHON-87 (psp_parser), and MODPYTHON-40 (file upload). Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher Ron Reisor [EMAIL PROTECTED] (RWR3) University of Delaware Information Technologies/Network and Systems Services Computing Center/192 South Chapel Street/Newark DE, 19716 pgp finger print: 0D 73 06 6F D3 6A 99 D3 F5 D5 6E FF 3B B9 7C 2C
Re: mod_python 3.2.5b available for testing
+1 on SuSE Linux 9.2 (x86-64) Best regards, Indrek Jim Gallacher wrote: A new mod_python 3.2.5 beta tarball is now available for testing. A windows binary should be available shortly. This release is similar to 3.2.4b but fixes a couple of minor issues - MODPYTHON-87 (psp_parser), and MODPYTHON-40 (file upload). Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: mod_python 3.2.5b available for testing (gentoo issues)
+1 with patch Linux gentoo 2.6.12-gentoo-r6 apache 2.0.54 (mpm-prefork) python 2.4.2 gcc 3.3.6 There are 2 issues with the unit tests in Gentoo that are fixed by the attached patch. (Just to be clear, I mean the problems are with the unit test code, not with mod_python). First, test_global_lock uses ab in the test. In Gentoo, ab is named ab2, so this test fails. The attached patch just skips the test if ab doesn't exist. We can improve on this later. The second issue is with test_req_headers_out, first reported by Dominic Wong a couple of weeks ago. The fix is simple, but I want to understand why it was failing under Gentoo and not other platforms. The culprit seems to be the use of DirectoryIndex directive in the test.conf. The existence of DirectoryIndex /tests.py causes apache to segfault. Removing DirectoryIndex and giving the full url in the putrequest allows the test to complete successfully. So my questions are: 1. Why would DirectoryIndex cause a segfault on gentoo but not other platforms? 2. This test is the only one that uses DirectoryIndex. Is there any special reason for this? 3. This test is the only one that uses AddHandler instead of SetHandler. Is there a reason for this? 4. This test is the only one that sets a PythonAccessHandler directive in test.conf. Is there a reason for this? Can anyone offer any insights? Regards, Jim Index: test/test.py === --- test/test.py(revision 344202) +++ test/test.py(working copy) @@ -136,7 +136,6 @@ MOD_PYTHON_SO = testconf.MOD_PYTHON_SO LIBEXECDIR = testconf.LIBEXECDIR AB = os.path.join(os.path.split(HTTPD)[0], ab) - SERVER_ROOT = TESTHOME CONFIG = os.path.join(TESTHOME, conf, test.conf) DOCUMENT_ROOT = os.path.join(TESTHOME, htdocs) @@ -379,7 +378,6 @@ return rsp ### Tests begin here - def test_req_document_root_conf(self): c = VirtualHost(*, @@ -668,8 +666,7 @@ ServerName(test_req_headers_out), DocumentRoot(DOCUMENT_ROOT), Directory(DOCUMENT_ROOT, - AddHandler(mod_python .py), - DirectoryIndex(/tests.py), + SetHandler(mod_python), PythonHandler(tests::req_headers_out), PythonAccessHandler(tests::req_headers_out_access), PythonDebug(On))) @@ -680,7 +677,7 @@ print \n * Testing req.headers_out conn = httplib.HTTPConnection(127.0.0.1:%s % PORT) -conn.putrequest(GET, /, skip_host=1) +conn.putrequest(GET, /tests.py, skip_host=1) conn.putheader(Host, test_req_headers_out:%s % PORT) conn.endheaders() response = conn.getresponse() @@ -1733,6 +1730,10 @@ t1 = time.time() print , time.ctime() ab = quoteIfSpace(AB) +if not os.path.exists(ab): +print ab not found. Skipping _global_lock test +return + if os.name == nt: cmd = '%s -c 5 -n 5 http://127.0.0.1:%s/tests.py NUL:' \ % (ab, PORT)
