|
Home > Archive > Apache Mod-Python > August 2005 > mod_python 3.2.0-BETA available for testing
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
mod_python 3.2.0-BETA available for testing
|
|
| Jim Gallacher 2005-08-17, 5:47 pm |
| 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 mod_python@modpython.org 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
| |
| Gregory (Grisha) Trubetskoy 2005-08-18, 2:46 am |
|
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 mod_python@modpython.org 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
>
| |
| Graham Dumpleton 2005-08-18, 7:46 am |
| 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 mod_python@modpython.org 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
| |
| Jim Gallacher 2005-08-18, 5:47 pm |
| 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 cannot
be found in your PATH configure will fail. If the wrong version is
found 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, so
a pre-generated copy of psp_parser.c is included with the source. If you
do 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-flex
option, 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 Makefile
manually. Other than the detection of the flex path, the behaviour is
the same as 3.1.x. The previous warning about needing the correct flex
version was just a comment in the Makefile. Any suggestions on how to
make 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:
>
>
>
| |
| Ron Reisor 2005-08-18, 5:47 pm |
| | |
| Nicolas Lehuen 2005-08-18, 5:47 pm |
| +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/...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,
Nicolas
2005/8/18, Jim Gallacher <jg.lists@sympatico.ca>:
>
> Graham Dumpleton wrote:
>
> 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 cannot
> be found in your PATH configure will fail. If the wrong version is
> found 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, so
> a pre-generated copy of psp_parser.c is included with the source. If you
> do 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-flex
> option, 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 Makefile
> manually. Other than the detection of the flex path, the behaviour is
> the same as 3.1.x. The previous warning about needing the correct flex
> version was just a comment in the Makefile. Any suggestions on how to
> make this clearer are welcome.
>
>
> No, see html docs snippet above.
>
> No time to look at the rest. Will comment tonight.
>
> Jim
>
> this
> have
> after
> anything
> better
> clearly
>
>
| |
| Jim Gallacher 2005-08-18, 5:47 pm |
| 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. ;)
Jim
| |
| Graham Dumpleton 2005-08-18, 5:47 pm |
|
On 19/08/2005, at 2:59 AM, Jim Gallacher wrote:
> Ron Reisor wrote:
>
> 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
| |
| Graham Dumpleton 2005-08-19, 7:49 am |
|
On 19/08/2005, at 7:57 AM, Graham Dumpleton wrote:
>
> On 19/08/2005, at 2:59 AM, Jim Gallacher wrote:
>
>
>
> 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.
The missing bit of information here is that Python on Tiger (10.4) is
correctly
putting in the config/Makefile used by distutils the required
options. Ie.,
LDSHARED= $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookup
BLDSHARED= $(CC) $(LDFLAGS) -bundle -undefined dynamic_lookup
The duplicated definition of the -undefined option causes grief when
setup.py
adds it as well.
Thus, setup.py will thus need to check first whether the -undefined
option
already 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 had
used which is '-undefined suppress'. If though you try and use '-
undefined
dynamic_lookup' on Panther (10.3) or earlier you will run up against a
further problem in that '-undefined dynamic_lookup' conflicts with the
default compilation mode of being compatible with Mac OS X 10.1. Thus,
still probably best to use '-undefined suppress', but the check means
that
it will only be used on older versions of Mac OS X anyway, or at
least where
the Python config isn't correct.
I'll attach a patch to the JIRA report on the original problem shortly.
Graham
| |
| Graham Dumpleton 2005-08-19, 7:49 am |
|
On 19/08/2005, at 8:01 PM, Graham Dumpleton wrote:
>
> Thus, setup.py will thus need to check first whether the -undefined
> option
> already 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 code
that worked on MAC OS X 10.3. :-)
Graham
| |
| Ron Reisor 2005-08-19, 7:49 am |
| 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:
>
>
> 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 <ron@udel.edu> (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
| |
| Ron Reisor 2005-08-19, 5:47 pm |
| With the "if not '-undefined' in" patch provided by Graham (thanks!),
everything seems to work on:
MacOSX 10.4.2
Apple provided gcc 4.0.0
python 2.4.1
apache 2.0.54
All of the tests in test/test.py pass OK!
+1
cheers,
Ron
Ron Reisor <ron@udel.edu> (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
| |
| Gregory (Grisha) Trubetskoy 2005-08-19, 5:47 pm |
|
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?
Grisha
On Wed, 17 Aug 2005, Gregory (Grisha) Trubetskoy wrote:
>
> 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:
>
>
| |
| Jim Gallacher 2005-08-19, 5:47 pm |
| 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 changed
behaviour of module loading in mod_python.publisher."
5. The default session class used when Session.Session() is called can
now be specified using "PythonOption session [MemorySession | DbmSession
| FileSession]". This did not make it into the documentation. Mea culpa.
Jim
>
> Grisha
>
>
> On Wed, 17 Aug 2005, Gregory (Grisha) Trubetskoy wrote:
>
>
| |
| Nicolas Lehuen 2005-08-19, 5:47 pm |
| 2005/8/19, Jim Gallacher <jg.lists@sympatico.ca>:
>
> Gregory (Grisha) Trubetskoy wrote:
>
> 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 changed
> behaviour of module loading in mod_python.publisher."
Here is the current documentation :
http://www.modpython.org/live/curre...b-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
|
|
|
|
|