Re: [jira] Created: (MODPYTHON-201) ReportError in importer.py raises an exception for mal-formed psp
Sometimes it's hard to keep up with you, Graham. ;)
Although I haven't been around much lately, I have been compiling and
testing the svn commits on a regular basis. As it happens, the machine I
used for this bug report was not one with the latest and greatest.
Jim
Graham Dumpleton wrote:
You don't have latest source code checked out from subversion. I
fixed that in a commit a few hours after I originally introduced it.
Also, I subsequently changed the code again after that and 'stime'
no longer exists, or at least it is called something different now.
Graham
On 04/11/2006, at 8:26 AM, Jim Gallacher (JIRA) wrote:
ReportError in importer.py raises an exception for mal-formed psp
-
Key: MODPYTHON-201
URL: http://issues.apache.org/jira/browse/MODPYTHON-201
Project: mod_python
Issue Type: Bug
Components: importer
Affects Versions: 3.3
Environment: 3.3.0-dev-20061029
Reporter: Jim Gallacher
Priority: Blocker
Mal formed psp causes an exception in importer.py ReportError
The following psp contains a syntax error, and generates an exception
as expected, causing importer.ReportError to be called.
test.psp
-
%
req.write('x'
%
There is bug in ReportError however that raises an exception, and a
500 Internal Server Error is sent to the client.
apache error_log
--
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] req.write(
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] ^
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] SyntaxError:
invalid syntax
Traceback (most recent call last):
File /usr/lib/python2.4/site-packages/mod_python/importer.py, line
1797, in ReportError
stime = time.asctime(time.localtime(modules.stime))
AttributeError: '_module_cache' object has no attribute 'stime'
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2]
python_handler: Dispatch() returned non-integer.
I'm not sure if this is a simple bug in ReportError, or indicates a
deeper problem with cache mechanism in the importer.
--This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MODPYTHON-201) ReportError in importer.py raises an exception for mal-formed psp
[ http://issues.apache.org/jira/browse/MODPYTHON-201?page=all ]
Jim Gallacher closed MODPYTHON-201.
---
Fix Version/s: 3.3
Resolution: Fixed
Already fixed in a more recent commit.
ReportError in importer.py raises an exception for mal-formed psp
-
Key: MODPYTHON-201
URL: http://issues.apache.org/jira/browse/MODPYTHON-201
Project: mod_python
Issue Type: Bug
Components: importer
Affects Versions: 3.3
Environment: 3.3.0-dev-20061029
Reporter: Jim Gallacher
Priority: Blocker
Fix For: 3.3
Mal formed psp causes an exception in importer.py ReportError
The following psp contains a syntax error, and generates an exception as
expected, causing importer.ReportError to be called.
test.psp
-
%
req.write('x'
%
There is bug in ReportError however that raises an exception, and a 500
Internal Server Error is sent to the client.
apache error_log
--
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] req.write(
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] ^
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] SyntaxError: invalid
syntax
Traceback (most recent call last):
File /usr/lib/python2.4/site-packages/mod_python/importer.py, line 1797,
in ReportError
stime = time.asctime(time.localtime(modules.stime))
AttributeError: '_module_cache' object has no attribute 'stime'
[Fri Nov 03 16:08:19 2006] [error] [client 192.168.1.2] python_handler:
Dispatch() returned non-integer.
I'm not sure if this is a simple bug in ReportError, or indicates a deeper
problem with cache mechanism in the importer.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Purpose of mp_conn.server member?
I was fixing a error in the new mp_conn.log_error method and I noticed that the connobject struct has a PyObject *server element. There is no corresponding apache conn_rec-server attribute, I don't see it being used anywhere in our code, and it is undocumented in mp_conn members. See src/connobject.c line 49 and src/include/connobject.h line 44 and http://www.modpython.org/live/current/doc-html/pyapi-mpconn-mem.html Does anyone know why it exists? It this some vestige from any earlier age that can be deleted? Jim
Are we ready for a 3.3 beta?
It sure feels like we are close thanks to Graham's hard work. I've been doing some testing and it's looking good. With 3.3.0-dev-20061104 (r471260): +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.3.5 +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.4.1 +1 Linux Ubuntu 6.06, Apache 2.0.55 (worker-mpm), python 2.4.3 +1 Linux Ubuntu 6.10, Apache 2.0.55 (prefork-mpm), python 2.4.4c1 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.3.5 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.4.4 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.5 I'm assuming we are *officially* dropping python 2.2 support, but it does still work as long as you are using the legacy importer. Also, I wonder if we should bump the apache version required to 2.0.54, or at least note in the docs that we haven't done any testing for version 2.0.54 (or 2.0.53 as the case may be). Anyway, are there any burning issues that need to be addressed beyond a couple of documentation tweaks? If not I'll roll a tarball for preliminary testing and if all goes well we can proceed to a beta release cycle in fairly quick order. Jim
Re: Are we ready for a 3.3 beta?
I'd really like to see MODPYTHON-195 fixed with what I've tested. It is a WIN32-only bug and fix. Restart of Apache on Win32 leaks one event handle every time if the fix is not applied. We have to run on Windows (long story there) and need to run long term leak-free. Thanks, Jeff - Original Message - From: Jim Gallacher [EMAIL PROTECTED] To: python-dev@httpd.apache.org Sent: Saturday, November 04, 2006 4:35 PM Subject: Are we ready for a 3.3 beta? It sure feels like we are close thanks to Graham's hard work. I've been doing some testing and it's looking good. With 3.3.0-dev-20061104 (r471260): +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.3.5 +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.4.1 +1 Linux Ubuntu 6.06, Apache 2.0.55 (worker-mpm), python 2.4.3 +1 Linux Ubuntu 6.10, Apache 2.0.55 (prefork-mpm), python 2.4.4c1 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.3.5 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.4.4 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.5 I'm assuming we are *officially* dropping python 2.2 support, but it does still work as long as you are using the legacy importer. Also, I wonder if we should bump the apache version required to 2.0.54, or at least note in the docs that we haven't done any testing for version 2.0.54 (or 2.0.53 as the case may be). Anyway, are there any burning issues that need to be addressed beyond a couple of documentation tweaks? If not I'll roll a tarball for preliminary testing and if all goes well we can proceed to a beta release cycle in fairly quick order. Jim
Re: Are we ready for a 3.3 beta?
Oops, sorry. I meant to include mention of that issue in my previous email. I agree that it should be fixed for 3.3. Jim Jeff Robbins wrote: I'd really like to see MODPYTHON-195 fixed with what I've tested. It is a WIN32-only bug and fix. Restart of Apache on Win32 leaks one event handle every time if the fix is not applied. We have to run on Windows (long story there) and need to run long term leak-free. Thanks, Jeff - Original Message - From: Jim Gallacher [EMAIL PROTECTED] To: python-dev@httpd.apache.org Sent: Saturday, November 04, 2006 4:35 PM Subject: Are we ready for a 3.3 beta? It sure feels like we are close thanks to Graham's hard work. I've been doing some testing and it's looking good. With 3.3.0-dev-20061104 (r471260): +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.3.5 +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.4.1 +1 Linux Ubuntu 6.06, Apache 2.0.55 (worker-mpm), python 2.4.3 +1 Linux Ubuntu 6.10, Apache 2.0.55 (prefork-mpm), python 2.4.4c1 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.3.5 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.4.4 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.5 I'm assuming we are *officially* dropping python 2.2 support, but it does still work as long as you are using the legacy importer. Also, I wonder if we should bump the apache version required to 2.0.54, or at least note in the docs that we haven't done any testing for version 2.0.54 (or 2.0.53 as the case may be). Anyway, are there any burning issues that need to be addressed beyond a couple of documentation tweaks? If not I'll roll a tarball for preliminary testing and if all goes well we can proceed to a beta release cycle in fairly quick order. Jim
Re: PSP Handler underscore trick
Incomplete documentation. For AddHandler it would always have required
the .psp_ extension case to be listed explicitly.
On 05/11/2006, at 3:04 AM, Jim Gallacher wrote:
I was doing a bit of work on the Docs and I noticed a problem with
the .psp_ trick to get the listing of the source and generated
code. This is not a feature I use so I'm not sure if the
documentation is incorrect or if the behaviour has changed. Simply
appending _ to the URL does not work as advertised.
eg.
URL
---
http://localhost/test.psp_
test.psp
%
req.write('hello world')
%
This configuration doesn't work - status 404
.htaccess
-
PythonDebug On
AddHandler mod_python .psp
PythonHandler mod_python.psp
This configuration works - status 200
.htaccess
-
PythonDebug On
AddHandler mod_python .psp .psp_
PythonHandler mod_python.psp
This configuration works - status 200
.htaccess
-
PythonDebug On
SetHandler mod_python
PythonHandler mod_python.psp
So what's up with this? Bad docs or has it changed?
Jim
Re: svn commit: r471255 - /httpd/mod_python/trunk/src/connobject.c
Cool. I said the correct thing in the JIRA issue, but then did the wrongthing in the code. :-)From JIRA. Note that ap_log_cerror() was only introduced during Apache 2.0.55. As a result, if an older version of Apache is used than that, instead of using ap_log_cerror(), it would use ap_log_error() and use req.connection.base_server as the server to log against. In doing this, the client information wouldn't be displayed though. GrahamOn 05/11/2006, at 7:12 AM, [EMAIL PROTECTED] wrote:Author: jgallacherDate: Sat Nov 4 12:12:40 2006New Revision: 471255URL: http://svn.apache.org/viewvc?view=revrev=471255Log:Fixed conn_log_cerror for apache 2.0.55 (ie AP_MAGIC less than 20020903.10).This function falls back to ap_log_error for earlier apache versions,but was passing conn-server instead of conn-base_server as an argument.(There is no conn_rec-server element).Modified: httpd/mod_python/trunk/src/connobject.cModified: httpd/mod_python/trunk/src/connobject.cURL: http://svn.apache.org/viewvc/httpd/mod_python/trunk/src/connobject.c?view=diffrev=471255r1=471254r2=471255==--- httpd/mod_python/trunk/src/connobject.c (original)+++ httpd/mod_python/trunk/src/connobject.c Sat Nov 4 12:12:40 2006@@ -76,7 +76,7 @@ #if AP_MODULE_MAGIC_AT_LEAST(20020903,10) ap_log_cerror(APLOG_MARK, level, 0, self-conn, "%s", message); #else- ap_log_error(APLOG_MARK, level, 0, self-conn-server, "%s", message);+ ap_log_error(APLOG_MARK, level, 0, self-conn-base_server, "%s", message); #endif }
Re: Are we ready for a 3.3 beta?
I want to get the session/cookie changes committed first. Also just noticed that one probably can't do: req.handler = None ie., set it to be unset. I can see I might want this for various reasons. :-) Once I have attended to that, only outstanding issue will be documentation updates for new module importer, but that doesn't need to stop a beta being done. Graham On 05/11/2006, at 8:35 AM, Jim Gallacher wrote: It sure feels like we are close thanks to Graham's hard work. I've been doing some testing and it's looking good. With 3.3.0-dev-20061104 (r471260): +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.3.5 +1 Linux Debian 3.1 Stable, Apache 2.0.54 (prefork-mpm), python 2.4.1 +1 Linux Ubuntu 6.06, Apache 2.0.55 (worker-mpm), python 2.4.3 +1 Linux Ubuntu 6.10, Apache 2.0.55 (prefork-mpm), python 2.4.4c1 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.3.5 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.4.4 +1 Linux Debian unstable, Apache 2.2.3 (worker-mpm), Python 2.5 I'm assuming we are *officially* dropping python 2.2 support, but it does still work as long as you are using the legacy importer. Also, I wonder if we should bump the apache version required to 2.0.54, or at least note in the docs that we haven't done any testing for version 2.0.54 (or 2.0.53 as the case may be). Anyway, are there any burning issues that need to be addressed beyond a couple of documentation tweaks? If not I'll roll a tarball for preliminary testing and if all goes well we can proceed to a beta release cycle in fairly quick order. Jim
[jira] Resolved: (MODPYTHON-198) Python 2.5 nested auth functions in publisher.
[ http://issues.apache.org/jira/browse/MODPYTHON-198?page=all ]
Graham Dumpleton resolved MODPYTHON-198.
Resolution: Fixed
Looks like JIRA is not showing subversion commits or has not recorded some from
when they were doing their infrastructure update. Is fixed though. Ended up
using:
func_code = func_object.func_code
func_globals = func_object.func_globals
def lookup(name):
i = None
if name in func_code.co_names:
i = list(func_code.co_names).index(name)
elif func_code.co_argcount len(func_code.co_varnames):
names = func_code.co_varnames[func_code.co_argcount:]
if name in names:
i = list(names).index(name)
if i is not None:
return (1, func_code.co_consts[i+1])
return (0, None)
(found_auth, __auth__) = lookup('__auth__')
if found_auth and type(__auth__) == types.CodeType:
__auth__ = new.function(__auth__, func_globals)
(found_access, __access__) = lookup('__access__')
if found_access and type(__access__) == types.CodeType:
__access__ = new.function(__access__, func_globals)
(found_realm, __auth_realm__) = lookup('__auth_realm__')
if found_realm:
realm = __auth_realm__
Ie., look in co_names first as co_varnames wasn't ordered correctly for older
versions of Python.
Python 2.5 nested auth functions in publisher.
--
Key: MODPYTHON-198
URL: http://issues.apache.org/jira/browse/MODPYTHON-198
Project: mod_python
Issue Type: Bug
Components: publisher
Affects Versions: 3.2.10
Reporter: Graham Dumpleton
Assigned To: Graham Dumpleton
Fix For: 3.3
Jim Gallacher wrote:
With python 2.5 I get 2 failures:
test_publisher_auth_nested
test_publisher_auth_method_nested
It looks like something has changed in python 2.5 introspection that is
messing up publisher.
Test script testme.py
-
def testfunc():
print 'stuff'
def __auth__():
print '__auth__ called'
def __access__():
print '__access__ called'
def main():
func_obj = testfunc
func_code = func_obj.func_code
print func_code.co_names
if __name__ == '__main__':
main()
Results
---
$ python2.3 testme.py
('__auth__', '__access__')
$ python2.4 testme.py
('__auth__', '__access__')
$ python2.5 testme.py
()
Dan Eloff points out that information is now in co_varnames.
fc.co_names
()
fc.co_varnames
('__auth__', '__access__')
def foo(a,b):
d = 5
def bar(c):
return c
fc.co_names
()
fc.co_varnames
('a', 'b', 'd', 'bar')
To get just args, try:
fc.co_varnames[:fc.co_argcount]
('a', 'b')
And for just local vars:
fc.co_varnames[fc.co_argcount:]
('d', 'bar')
Still need to work out if actual code objects for the functions are available
in co_consts or not. Ie., need to replace:
if __auth__ in func_code.co_names:
i = list(func_code.co_names).index(__auth__)
__auth__ = func_code.co_consts[i+1]
if hasattr(__auth__, co_name):
__auth__ = new.function(__auth__, func_globals)
found_auth = 1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=all ] Graham Dumpleton resolved MODPYTHON-93. --- Resolution: Fixed Not heard of anyone who has specifically tested to see if this works with older versions of Trac or not, but code passing tests on various Python/Apache versions so that's good enough for now. Improve util.FieldStorage efficiency Key: MODPYTHON-93 URL: http://issues.apache.org/jira/browse/MODPYTHON-93 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.2.7 Reporter: Jim Gallacher Assigned To: Graham Dumpleton Priority: Minor Fix For: 3.3 Attachments: modpython325_util_py_dict.patch Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour. This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created. Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
