Re: mod_python 3.2.0-BETA available for testing
2005/8/19, Jim Gallacher <[EMAIL PROTECTED]>: Gregory (Grisha) Trubetskoy wrote:>> OK, looks like the test failure that I was seeing was more caused by my> environment, so all tests pass.>> So we've got:>> 1. flex> > 2. MacOS compile>> 3. http://issues.apache.org/jira/browse/MODPYTHON-72> Is this all?4. From Graham: "Only other issue at the moment I can think of is whether or not anything prominent has been put in main documentation about changedbehaviour of module loading in mod_python.publisher." Here is the current documentation : http://www.modpython.org/live/current/doc-html/hand-pub-alg-trav.html The arcane changes that the new behaviour introduces are way, way out of scope with regards to this documentation. The current documentation says "The Publisher handler locates and imports the module specified in the URI. The module location is determined from the req.filename attribute. Before importing, the file extension, if any, is discarded.". Well, apart from the MODPYTHON-72 bug, the new behaviour just does the same thing. Regards, Nicolas
Re: mod_python 3.2.0-BETA available for testing
Oops, it's MacOSX 10.4.2, not MacOSX 1.4.2 -- sorry. [zim:~] ron% gcc --version powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer, Inc. build 4061) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [zim:~] ron% I'm using the gcc that Apple provides with the developers package. extra info: Tiger includes python 2.3.5 as /usr/bin/python, but I am not using that. Python 2.4.1 has been built into /Library/Frameworks and /usr/local/bin/python and that's what mod_python is using. I'm using an apache 2.0.54 that I built myself into /usr/local. cheers, Ron On Fri, 19 Aug 2005, Graham Dumpleton wrote: On 19/08/2005, at 2:59 AM, Jim Gallacher wrote: Ron Reisor wrote: Hello, I ran into a problem with the loader on MacOSX. MaxOSX 1.4.2 python 2.4.1 apache 2.0.54 The loader seems to not like the "-undefined suppress" arguments in the final load. I modified dist/setup.py by removing the two "-undefined suppress" and ran configure and make again and the new mod_python does build and seems to work ok. The bit of code which includes "-undefined suppress" came from the patch Graham submitted for MODPYTHON-65. See http://issues.apache.org/jira/browse/MODPYTHON-65 for details. Not being a Mac person I can't comment further. Feel free to talk among yourselves. ;) Yep, my fault. It will not build on Mac OS X 10.3.9 without that option if you are using the standard version of GCC shipped with the operating system. I'll get onto my new Tiger laptop and try it there (haven't yet), but can you tell me which GCC you are using? I know the GCC version shipped on the box with Tiger, but are you using that, or are you using one supplied with Fink? Was worried that the change might not apply to the Fink version of GCC. Graham 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.0-BETA available for testing
On 19/08/2005, at 8:01 PM, Graham Dumpleton wrote:Thus, setup.py will thus need to check first whether the -undefined optionalready exists. Thus, setup.py should use:if sys.platform == "darwin": if not '-bundle' in sysconfig.get_config_var("LDSHARED").split(): sysconfig._config_vars["LDSHARED"] = \ string.replace(sysconfig.get_config_var("LDSHARED"), \ " -bundle "," -bundle -flat_namespace -undefined suppress ") sysconfig._config_vars["BLDSHARED"] = \ string.replace(sysconfig.get_config_var("BLDSHARED"), \ " -bundle "," -bundle -flat_namespace -undefined suppress ")Whoops, that should be: if not '-undefined' in .The patch I attached to JIRA report is correct as it is a diff from actual codethat worked on MAC OS X 10.3. :-)Graham
Re: mod_python 3.2.0-BETA available for testing
On 19/08/2005, at 7:57 AM, Graham Dumpleton wrote:On 19/08/2005, at 2:59 AM, Jim Gallacher wrote: Ron Reisor wrote: Hello,I ran into a problem with the loader on MacOSX.MaxOSX 1.4.2python 2.4.1apache 2.0.54The loader seems to not like the "-undefined suppress" arguments in the final load.I modified dist/setup.py by removing the two "-undefined suppress" and ran configure and make again and the new mod_python does build and seems to work ok. The bit of code which includes "-undefined suppress" came from the patch Graham submitted for MODPYTHON-65. See http://issues.apache.org/jira/browse/MODPYTHON-65 for details.Not being a Mac person I can't comment further. Feel free to talk among yourselves. ;) Yep, my fault. It will not build on Mac OS X 10.3.9 without that option ifyou are using the standard version of GCC shipped with the operatingsystem.I'll get onto my new Tiger laptop and try it there (haven't yet), but canyou tell me which GCC you are using? I know the GCC version shipped on thebox with Tiger, but are you using that, or are you using one supplied withFink? Was worried that the change might not apply to the Fink version of GCC.The missing bit of information here is that Python on Tiger (10.4) is correctlyputting in the config/Makefile used by distutils the required options. Ie., LDSHARED= $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookup BLDSHARED= $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookupThe duplicated definition of the -undefined option causes grief when setup.pyadds it as well.Thus, setup.py will thus need to check first whether the -undefined optionalready exists. Thus, setup.py should use:if sys.platform == "darwin": if not '-bundle' in sysconfig.get_config_var("LDSHARED").split(): sysconfig._config_vars["LDSHARED"] = \ string.replace(sysconfig.get_config_var("LDSHARED"), \ " -bundle "," -bundle -flat_namespace -undefined suppress ") sysconfig._config_vars["BLDSHARED"] = \ string.replace(sysconfig.get_config_var("BLDSHARED"), \ " -bundle "," -bundle -flat_namespace -undefined suppress ")In Tiger it actually uses '-undefined dynamic_lookup' instead of what I hadused which is '-undefined suppress'. If though you try and use '-undefineddynamic_lookup' on Panther (10.3) or earlier you will run up against afurther problem in that '-undefined dynamic_lookup' conflicts with thedefault compilation mode of being compatible with Mac OS X 10.1. Thus,still probably best to use '-undefined suppress', but the check means thatit will only be used on older versions of Mac OS X anyway, or at least wherethe Python config isn't correct.I'll attach a patch to the JIRA report on the original problem shortly.Graham
Re: mod_python 3.2.0-BETA available for testing
On 19/08/2005, at 2:59 AM, Jim Gallacher wrote: Ron Reisor wrote: Hello, I ran into a problem with the loader on MacOSX. MaxOSX 1.4.2 python 2.4.1 apache 2.0.54 The loader seems to not like the "-undefined suppress" arguments in the final load. I modified dist/setup.py by removing the two "-undefined suppress" and ran configure and make again and the new mod_python does build and seems to work ok. The bit of code which includes "-undefined suppress" came from the patch Graham submitted for MODPYTHON-65. See http://issues.apache.org/jira/browse/MODPYTHON-65 for details. Not being a Mac person I can't comment further. Feel free to talk among yourselves. ;) Yep, my fault. It will not build on Mac OS X 10.3.9 without that option if you are using the standard version of GCC shipped with the operating system. I'll get onto my new Tiger laptop and try it there (haven't yet), but can you tell me which GCC you are using? I know the GCC version shipped on the box with Tiger, but are you using that, or are you using one supplied with Fink? Was worried that the change might not apply to the Fink version of GCC. Graham
Re: mod_python 3.2.0-BETA available for testing
+1 on Win32 with Python 2.4. Here is how I tested it : 1) Switched to the 3.2.0-BETA tag 2) Update 3) cd dist & build_installer.bat 4) Got this installer, that you can also download : http://nicolas.lehuen.com/download/mod_python/mod_python-3.2.0-BETA.win32-py2.4.exe 5) Ran the installer, everything installed correctly 6) cd test & python test.py, all unit test pass 7) Used the test handler to check various version information 8) Made a few test this my own applications, everything seems OK (which is not a big surprise since I used the dev version before). Regards, Nicolas2005/8/18, Jim Gallacher <[EMAIL PROTECTED]>: Graham Dumpleton wrote:> A few comments:>> 1. If you have an older version of flex than that expected, it gives> message:>> checking flex version... configure: WARNING: Flex version 2.5.31 or> greater is required. The one you have seems to be 2.5.4. Use> --with-flex to specify another.>> There is nothing in the README describing why such a requirement exists.> The only veiled comment is in the "configure" script itself where it > says:>> # check for correct flex version> # requires flex 2.5.31 for reentrant support>> A more prominent explanation is required in the README with "configure" > outputing with the message above a pointer to consult the README for> further details.>> What also isn't at all clear, is whether the flex warning is relevant> anyway if pre-generated code for the lexical analyser is provided in the > tar ball and that is used.This is explained in the html docs, but didn't make it into the README.I wasn't sure if the WARNING was the right idea,See doc-html/inst-configure.html: """ Attempts to locate flex and determine its version. If flex cannotbe found in your PATH configure will fail. If the wrong version isfound configure will generate a warning. You can generally ignore this warning unless you need to re-create src/psp_parser.c.The parser used by psp (See 4.9) is written in C generated using flex.This requires a reentrant version of flex which at this time is 2.5.31.Most platforms however ship with version 2.5.4 which is not suitable, soa pre-generated copy of psp_parser.c is included with the source. If youdo need to compile src/psp_parser.c you must get the correct flex version. If the first flex binary in the path is not suitable or not the one desired you can specify an alternative location with the --with-flexoption, e.g: $ ./configure --with-flex=/usr/local/bin/flex"""I'll copy this into the README as well. In 3.1.x the path to flex was hard coded to /usr/local/bin, which caused compilation to fail and required the user to edit the Makefilemanually. Other than the detection of the flex path, the behaviour is the same as 3.1.x. The previous warning about needing the correct flexversion was just a comment in the Makefile. Any suggestions on how tomake this clearer are welcome.> Thus, what is the real story, am I going to have a problem or not if > I have an older version of flex?No, see html docs snippet above.No time to look at the rest. Will comment tonight.Jim>> 2. Publisher still doesn't check special extensions supplied by the > AddHandler or PythonHandler directives. Ie.,>> http://issues.apache.org/jira/browse/MODPYTHON-72>> This may mean that code that previously worked no longer works. Ie., this > feature was in there before. Only caveat is that the feature may not have> worked properly before anyway, so existing code may not be affected after> all. See:>> http://issues.apache.org/jira/browse/MODPYTHON-22>> Bit unsure on this one.>> 3. Only other issue at the moment I can think of is whether or not anything> prominent has been put in main documentation about changed behaviour of > module> loading in mod_python.publisher. In the main the changes are for the better> and things will actually work better.>> There is one case though where existing code can stop working. This is > where> code makes an assumption that global data within a publisher module is> preserved> across module reloads.>> I am not saying this change is wrong, but it perhaps may need to be clearly > explained in documentation else we will get lots of questions about it> no doubt, with the common answer probably being that they shouldn't be> storing> such persistent module data in a module that can be reloaded anyway. >> Thats all for now until I can get some real time to look at it. :-)>> Graham On 18/08/2005, at 4:03 AM, Jim Gallacher wrote:>>> 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
Re: mod_python 3.2.0-BETA available for testing
Hello, I ran into a problem with the loader on MacOSX. MaxOSX 1.4.2 python 2.4.1 apache 2.0.54 The loader seems to not like the "-undefined suppress" arguments in the final load. I modified dist/setup.py by removing the two "-undefined suppress" and ran configure and make again and the new mod_python does build and seems to work ok. test.py can not find the apache log file after it has shut down apache, after all of the other tests pass! This may be cause by my installation of apache and may not be a mod_python problem, but I'll need to look further. cheers, Ron 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 2Cchecking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ar... ar checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets $(MAKE)... yes checking for main in -lm... yes checking for an ANSI C-conforming const... yes checking your blood pressure... a bit high, but we can proceed configure: checking whether apxs is available... checking for --with-apxs... /usr/local/bin/apxs executable, good checking Apache version... 2.0.54 checking for Apache libexec directory... /usr/local/modules checking for Apache include directory... -I/usr/local/include checking for --with-python... no checking for python... /usr/local/bin/python checking Python version... 2.4 checking Python install prefix... /Library/Frameworks/Python.framework/Versions/2.4 checking what libraries Python was linked with... -framework Python-ldl checking linker flags used to link Python... checking where Python include files are... -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 checking for --with-python-src... no checking for --with-flex... no checking for flex... /usr/bin/flex found /usr/bin/flex, we'll use this. Use --with-flex to specify another. checking flex version... configure: WARNING: Flex version 2.5.31 or greater is required. The one you have seems to be 2.5.4. Use --with-flex to specify another. checking for --with-max-locks... no Using 8 MAX_LOCKS. configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating Doc/Makefile config.status: creating src/include/mod_python.h config.status: creating test/testconf.py config.status: creating dist/setup.py config.status: creating dist/Makefile log.make Description: Binary data
Re: mod_python 3.2.0-BETA available for testing
A few comments: 1. If you have an older version of flex than that expected, it gives message: checking flex version... configure: WARNING: Flex version 2.5.31 or greater is required. The one you have seems to be 2.5.4. Use --with-flex to specify another. There is nothing in the README describing why such a requirement exists. The only veiled comment is in the "configure" script itself where it says: # check for correct flex version # requires flex 2.5.31 for reentrant support A more prominent explanation is required in the README with "configure" outputing with the message above a pointer to consult the README for further details. What also isn't at all clear, is whether the flex warning is relevant anyway if pre-generated code for the lexical analyser is provided in the tar ball and that is used. Thus, what is the real story, am I going to have a problem or not if I have an older version of flex? 2. Publisher still doesn't check special extensions supplied by the AddHandler or PythonHandler directives. Ie., http://issues.apache.org/jira/browse/MODPYTHON-72 This may mean that code that previously worked no longer works. Ie., this feature was in there before. Only caveat is that the feature may not have worked properly before anyway, so existing code may not be affected after all. See: http://issues.apache.org/jira/browse/MODPYTHON-22 Bit unsure on this one. 3. Only other issue at the moment I can think of is whether or not anything prominent has been put in main documentation about changed behaviour of module loading in mod_python.publisher. In the main the changes are for the better and things will actually work better. There is one case though where existing code can stop working. This is where code makes an assumption that global data within a publisher module is preserved across module reloads. I am not saying this change is wrong, but it perhaps may need to be clearly explained in documentation else we will get lots of questions about it no doubt, with the common answer probably being that they shouldn't be storing such persistent module data in a module that can be reloaded anyway. Thats all for now until I can get some real time to look at it. :-) Graham On 18/08/2005, at 4:03 AM, Jim Gallacher wrote: 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
Re: mod_python 3.2.0-BETA available for testing
OK, I think I have a -1 :-( checking for flex... no configure: error: flex binary not found in path flex shouldn't be required for build since the flex-generated psp_parser.c is already included? Aside from this I had a few tests fail - I'll have to take a look at the details tomorrow. This was on Fedora Core 4. Grisha On Wed, 17 Aug 2005, Jim Gallacher wrote: 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
