[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 10:47
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken
Initial Comment:
My python programs using curses library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-15 09:05
Message:
Logged In: YES
user_id=21627
I couldn't reproduce the problem on a Linux console
(although my console had a different size); so it remains
unreproducable for me.
--
Comment By: nomind (vnainar)
Date: 2006-04-13 13:00
Message:
Logged In: YES
user_id=1493752
Well , it is the linux console (in VGA mode ).
The local is en_US.The size of the console is
100X37.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 07:32
Message:
Logged In: YES
user_id=21627
Ah, ok. vnainar, atler_: What terminal had you been using to
make it crash? What is your locale? Any other conditions
that might be relevant (e.g. dimension of the terminal)?
--
Comment By: nomind (vnainar)
Date: 2006-04-11 07:13
Message:
Logged In: YES
user_id=1493752
Removing 'ncursesw' (there are two references to it in
'setup.py') seems to solve the problem. I noticed one more
oddity. Even before the above recompilation , it ran fine
on an Xterm !
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 00:28
Message:
Logged In: YES
user_id=21627
That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).
--
Comment By: Jan Palus (atler_)
Date: 2006-04-10 23:24
Message:
Logged In: YES
user_id=1497957
loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.
What is actual problem then? Something with ncursesw or
with python?
Anyway, Thanks for your help.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 22:58
Message:
Logged In: YES
user_id=21627
atler_: around line 427, you find
if self.compiler.find_library_file(lib_dirs,
'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
'ncurses'):
Replace that with
if self.compiler.find_library_file(lib_dirs,
'ncurses'):
(i.e. dropping the ncursesw part), and rebuild.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 15:48
Message:
Logged In: YES
user_id=1497957
More complete backtrace, I hope it will help:
http://pastebin.com/649445
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 14:14
Message:
Logged In: YES
user_id=29957
The buildbot boxes don't show this problem.
You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 12:51
Message:
Logged In: YES
user_id=1497957
$ ldd /usr/lib/python2.4/lib-dynload/_curses.so
libncursesw.so.5 => /usr/lib/libncursesw.so.5
(0x7004c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7008)
libc.so.6 => /lib/libc.so.6 (0x700e4000)
libdl.so.2 => /lib/libdl.so.2 (0x70228000)
libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000)
/lib/ld-linux.so.2 (0x7000)
...
Program received signal SIGSEGV, Segmentation fault.
0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
gdb) bt
#0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5
#1 0x706254b8 in ?? () from
/usr/lib/python2.4/lib-dynload/_curses_panel.so
#2 0x706254b8 in ?? () from
/usr/li
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 23:11
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on FreeBSD 4.x
Initial Comment:
$ ./python Lib/test/regrtest.py test_ctypes
test_ctypes
test test_ctypes failed -- Traceback (most recent call
last):
File
"/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py",
line 333, in test_struct_return_2H
self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (-1004, 2123) != (198, 264)
1 test failed:
test_ctypes
[41158 refs]
This is with a subversion checkout updated to 5am AEST
(Aust) 14Apr06, debug build.
The returned tuple values (s2h.x, s2h.y) appear to vary
from run to run, so it looks like something isn't where
its expected.
This is with a FreeBSD 4.8 i386 system (not
particularly recent), using gcc 2.95.4. A quick and
dirty test (in C) suggests that its not an alignment
issue for the 2 shorts in the S2H struct.
Ideas for trying to debug this further?
--
>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-15 21:18
Message:
Logged In: YES
user_id=250749
Your suggested change does indeed get the test to pass on
this system. Given the history and relationship of
[Free/Net/Open]BSD, I would suggest that for x86 it is very
likely that you will need to add defined(__NetBSD__) clauses
as well.
>From my POV this bug can now be closed.
Thanks, Thomas.
BTW, the actual patch applied was:
--- ffi.c.orig Tue Apr 4 05:26:32 2006
+++ ffi.c Sat Apr 15 21:02:16 2006
@@ -121,7 +121,7 @@
switch (cif->rtype->type)
{
case FFI_TYPE_VOID:
-#if !defined(X86_WIN32) && !defined(__OpenBSD__)
+#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
#endif
case FFI_TYPE_SINT64:
@@ -135,7 +135,7 @@
cif->flags = FFI_TYPE_SINT64;
break;
-#if defined(X86_WIN32) || defined(__OpenBSD__)
+#if defined(X86_WIN32) || defined(__OpenBSD__) ||
defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
if (cif->rtype->size == 1)
{
--
Comment By: Thomas Heller (theller)
Date: 2006-04-15 05:09
Message:
Logged In: YES
user_id=11105
Of course I meant FreeBSD instead of NetBSD, sorry.
--
Comment By: Thomas Heller (theller)
Date: 2006-04-15 05:08
Message:
Logged In: YES
user_id=11105
This looks very similar to a problem I recently 'fixed' on
OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86
the problem seemed to be that small structures are passed
like short or int. You could try to fix it by adding the
appropriate definition in
Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines
138. Maybe changing them to
#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__NetBSD__)
or whatever the magic symbol for Netbsd is.
Unfortunately I do not have access to a netbsd machine myself.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 10:47
Message generated for change (Comment added) made by atler_
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken
Initial Comment:
My python programs using curses library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library
--
Comment By: Jan Palus (atler_)
Date: 2006-04-15 16:48
Message:
Logged In: YES
user_id=1497957
Half day of debugging and it seems that I found an answer...
just by accident ;).
When curses module is linked against ncursesw it seems that
it also should be linked against panelw not plain panel.
After changing this in setup.py, ncurses.py demo finally
runs fine.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-15 09:05
Message:
Logged In: YES
user_id=21627
I couldn't reproduce the problem on a Linux console
(although my console had a different size); so it remains
unreproducable for me.
--
Comment By: nomind (vnainar)
Date: 2006-04-13 13:00
Message:
Logged In: YES
user_id=1493752
Well , it is the linux console (in VGA mode ).
The local is en_US.The size of the console is
100X37.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 07:32
Message:
Logged In: YES
user_id=21627
Ah, ok. vnainar, atler_: What terminal had you been using to
make it crash? What is your locale? Any other conditions
that might be relevant (e.g. dimension of the terminal)?
--
Comment By: nomind (vnainar)
Date: 2006-04-11 07:13
Message:
Logged In: YES
user_id=1493752
Removing 'ncursesw' (there are two references to it in
'setup.py') seems to solve the problem. I noticed one more
oddity. Even before the above recompilation , it ran fine
on an Xterm !
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 00:28
Message:
Logged In: YES
user_id=21627
That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).
--
Comment By: Jan Palus (atler_)
Date: 2006-04-10 23:24
Message:
Logged In: YES
user_id=1497957
loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.
What is actual problem then? Something with ncursesw or
with python?
Anyway, Thanks for your help.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 22:58
Message:
Logged In: YES
user_id=21627
atler_: around line 427, you find
if self.compiler.find_library_file(lib_dirs,
'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
'ncurses'):
Replace that with
if self.compiler.find_library_file(lib_dirs,
'ncurses'):
(i.e. dropping the ncursesw part), and rebuild.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 15:48
Message:
Logged In: YES
user_id=1497957
More complete backtrace, I hope it will help:
http://pastebin.com/649445
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 14:14
Message:
Logged In: YES
user_id=29957
The buildbot boxes don't show this problem.
You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 12:51
Message:
Logged In: YES
user_id=1497957
$ ldd /usr/lib/python2.4/lib-dynload/_curses.so
libncursesw.so.5 => /usr/lib/libncursesw.so.5
(0x7004c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7008)
libc.so.6 => /lib/libc.so.6 (0x700e4000)
libd
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 10:47
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: nomind (vnainar)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses library in python 2.4.3 broken
Initial Comment:
My python programs using curses library do not work
with version 2.4.3.Even the 'ncurses.py ' demo program
in the Demo/curses directory does not work correctly.
The problem seems to be in the 'panels' library
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-15 17:30
Message:
Logged In: YES
user_id=21627
Good spotting! Can everybody please confirm that the
attached patch fixes the problem?
--
Comment By: Jan Palus (atler_)
Date: 2006-04-15 16:48
Message:
Logged In: YES
user_id=1497957
Half day of debugging and it seems that I found an answer...
just by accident ;).
When curses module is linked against ncursesw it seems that
it also should be linked against panelw not plain panel.
After changing this in setup.py, ncurses.py demo finally
runs fine.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-15 09:05
Message:
Logged In: YES
user_id=21627
I couldn't reproduce the problem on a Linux console
(although my console had a different size); so it remains
unreproducable for me.
--
Comment By: nomind (vnainar)
Date: 2006-04-13 13:00
Message:
Logged In: YES
user_id=1493752
Well , it is the linux console (in VGA mode ).
The local is en_US.The size of the console is
100X37.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 07:32
Message:
Logged In: YES
user_id=21627
Ah, ok. vnainar, atler_: What terminal had you been using to
make it crash? What is your locale? Any other conditions
that might be relevant (e.g. dimension of the terminal)?
--
Comment By: nomind (vnainar)
Date: 2006-04-11 07:13
Message:
Logged In: YES
user_id=1493752
Removing 'ncursesw' (there are two references to it in
'setup.py') seems to solve the problem. I noticed one more
oddity. Even before the above recompilation , it ran fine
on an Xterm !
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 00:28
Message:
Logged In: YES
user_id=21627
That's hard to tell. Somebody would have to debug ncurses to
find out why it crashes. Notice that it crashes only on some
installations, so it is likely rather a problem with your
ncurses installation, than with Python (or even with ncurses
itself).
--
Comment By: Jan Palus (atler_)
Date: 2006-04-10 23:24
Message:
Logged In: YES
user_id=1497957
loewis: removing lines refering to ncursesw solves the
problem. ncurses.py runs fine as well as other programs.
What is actual problem then? Something with ncursesw or
with python?
Anyway, Thanks for your help.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-09 22:58
Message:
Logged In: YES
user_id=21627
atler_: around line 427, you find
if self.compiler.find_library_file(lib_dirs,
'ncursesw'):
readline_libs.append('ncursesw')
elif self.compiler.find_library_file(lib_dirs,
'ncurses'):
Replace that with
if self.compiler.find_library_file(lib_dirs,
'ncurses'):
(i.e. dropping the ncursesw part), and rebuild.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 15:48
Message:
Logged In: YES
user_id=1497957
More complete backtrace, I hope it will help:
http://pastebin.com/649445
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-09 14:14
Message:
Logged In: YES
user_id=29957
The buildbot boxes don't show this problem.
You might need to rebuild a Python with -g and unstripped to
get a useful backtrace.
--
Comment By: Jan Palus (atler_)
Date: 2006-04-09 12:51
Message:
Logged
[ python-Bugs-1448934 ] urllib2+https+proxy not working
Bugs item #1448934, was opened at 2006-03-13 15:55 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448934&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Rui Martins (ruibmartins) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2+https+proxy not working Initial Comment: Using urllib2 to access an https site using a proxy doesn't work. It always returns " " I've been looking around for bug reports on this and code samples, but all that I've got were emails/forum posts dating back to 2003 warning that the HTTPS over Proxy in urllib2 isn't implemented in Python! Is this true? -- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:27 Message: Logged In: YES user_id=261020 Yes, there is no special support for using https proxies (via the CONNECT method) in httplib or urllib2. http://python.org/sf/515003 shows how to do it, but the patch is not good enough to be added to the standard library. Feel free to write a better patch! Please close this, since it's really a feature request, not a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448934&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-944394 ] No examples or usage docs for urllib2
Bugs item #944394, was opened at 2004-04-29 12:02 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris -- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. -- Comment By: Chris Withers (fresh) Date: 2004-06-01 09:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... -- Comment By: Martin v. Löwis (loewis) Date: 2004-05-31 22:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr
Bugs item #900898, was opened at 2004-02-20 06:51
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: James Kruth (jk7)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr
Initial Comment:
If the Request object being used returns a URI with a
port included (e.g. http://www.mysite.com:/index.html)
If Request.get_full_url() or Request.get_host() returns
a URI or host with a port included (e.g.
http://www.mysite.com:/index.html or
www.mysite.com:, respectively), and authentication
(proxy or http, basic only) is required, then the
respective AuthHandlers (HTTPBasicAuthHandler,
ProxyBasicAuthHandler) end up calling
http_error_auth_reqed with a host looking like
"www.mysite.com:". http_error_auth_reqed then
precedes to call retry_http_basic_auth with the same
host parameter, which in turn calls
HTTPPasswordMgr.find_user_password. The problem is
that find_user_password appears to expect a full URI,
and attempts to reduce it to just a host, by calling
reduce_uri. If a bare host with a port is passed (like
"www.mysite.com:"), then reduce_uri returns just
the port number in the netloc position - which
find_user_password then attempts to compare against the
correct host name you've stored in your HTTPPasswordMgr
object along with your user name and password. I
believe either find_user_password should not reduce the
host, or the Auth Handler objects should pass full
hostnames to find_user_password.
--
Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:59
Message:
Logged In: YES
user_id=261020
This is fixed by patch 1470846, which includes tests and doc
fix / update (though I neglected to mention that the patch
fixes this problem in the initial patch comment; I'll
rectify that now).
--
Comment By: Brad Clements (bkc)
Date: 2004-04-06 20:58
Message:
Logged In: YES
user_id=4631
I ran into this problem today with Python 2.3.3 on RedHat 9.
I'm using port numbers in my URLs, and I found that the Auth
Handler did NOT correctly find the userid and password
registered.
ie:
authinfo = urllib2.HTTPPasswordMgrWithDefaultRealm()
authinfo.add_password(None, host, userid, password)
authHandler = urllib2.HTTPBasicAuthHandler(authinfo)
opener = urllib2.build_opener(authHandler)
where host = "http://localhost:7993";
I've tested the proposed fix shown in urllib2_bug.py at line 31,
to whit, this:
class HTTPBasicAuthHandlerF(AbstractBasicAuthHandler,
BaseHandler):
auth_header = 'Authorization'
def http_error_401(self, req, fp, code, msg, headers):
host = req.get_full_url()
return self.http_error_auth_reqed('www-authenticate',
host, req, headers)
This appears to have corrected the problem.
test_urllib2.py and test_urllib.py both pass after making
this change. I did not test the ProxyBasicAuthHandler change
(I don't have a proxy)
--
Comment By: James Kruth (jk7)
Date: 2004-02-20 21:25
Message:
Logged In: YES
user_id=979977
Here's a sample of the problem...
--
Comment By: James Kruth (jk7)
Date: 2004-02-20 14:39
Message:
Logged In: YES
user_id=979977
I've made up a file with some source code and comments that
will hopefully clarify what I posted. I will post an
example of the problem a bit later today.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-944394 ] No examples or usage docs for urllib2
Bugs item #944394, was opened at 2004-04-29 11:02 Message generated for change (Comment added) made by fresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris -- >Comment By: Chris Withers (fresh) Date: 2006-04-15 18:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. -- Comment By: John J Lee (jjlee) Date: 2006-04-15 17:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. -- Comment By: Chris Withers (fresh) Date: 2004-06-01 08:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... -- Comment By: Martin v. Löwis (loewis) Date: 2004-05-31 21:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-680577 ] urllib2 authentication problem
Bugs item #680577, was opened at 2003-02-05 00:22
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 authentication problem
Initial Comment:
I've found a problem using the authentication in urllib2.
When matching up host-names in order to find a
password, then putting the protocol in the address
makes it seem like a different address. eg...
I create a HTTPBasicAuthHandler with a
HTTPPasswordMgrWithDefaultRealm, and add the tuple
(None, "http://proxy.blah.com:17828";, "foo",
"bar") to it.
I then setup the proxy to use
http://proxy.blah.com:17828 (which requires
authentication).
When I connect, the password lookup fails, because it
is trying to find a match for "proxy.blah.com:17828"
rather than "http://proxy.blah.com:17828";
This problem doesn't exist if I pass
"proxy.blah.com:17828" to the password manager.
There seems to be some stuff in HTTPPasswordMgr to deal
with variations on site names, but I guess it's not
working in this case (unless this is intentional).
Version Info:
Python 2.2 (#1, Feb 24 2002, 16:21:58)
[GCC 2.96 2731 (Mandrake Linux 8.2 2.96-0.76mdk)]
on linux-i386
--
Comment By: John J Lee (jjlee)
Date: 2006-04-15 19:45
Message:
Logged In: YES
user_id=261020
This issue is fixed by patch 1470846.
--
Comment By: John J Lee (jjlee)
Date: 2003-12-16 12:49
Message:
Logged In: YES
user_id=261020
Thanks!
It seems .reduce_uri() tries to cope with hostnames as well as
absoluteURIs. I don't understand why it wants to do that, but it
fails, because it doesn't anticipate what urlparse does when a
port is present:
>>> urlparse.urlparse("foo.bar.com")
('', '', 'foo.bar.com', '', '', '')
>>> urlparse.urlparse("foo.bar.com:80")
('foo.bar.com', '', '80', '', '', '')
I haven't checked, but I assume it's just incorrect use of
urlparse to pass it a hostname.
Of course, if it's "fixed" to only accept absoluteURIs, it will
break existing code, so I guess it must be fixed for
hostnames. :-((
Also, I think .is_suburi("/foo/spam", "/foo/eggs") should
return
False, but returns True, and .http_error_40x() use
req.get_host() when they should be using req.get_full_url()
(from a quick look at RFC 2617).
--
Comment By: GaryD (gazzadee)
Date: 2003-12-16 03:10
Message:
Logged In: YES
user_id=693152
Okay, I have attached a file that replicates this problem.
If you run it as is (replacing the proxy name and address
with something suitable), then it will fail (requiring proxy
authentication).
If you uncomment line 23 (which specifies the password
without the scheme), then it will work successfully.
Technical Info:
* For a proxy, I am using Squid Cache version 2.4.STABLE7
for i586-mandrake-linux-gnu...
* I have replicated the problem with Python 2.2.2 on Linux,
and Python 2.3.2 on Windows XP.
--
Comment By: GaryD (gazzadee)
Date: 2003-12-16 02:08
Message:
Logged In: YES
user_id=693152
This was a while ago, and my memory has faded. I'll try to
respond intelligently.
I think the question was with the way the password manager
looks up passwords, rather than anything else.
I am pretty sure that the problem is not to do with the URI
passed to urlopen(). In the code shown below, the problem
was solely dependent on whether I added the line:
(None, "blah.com:17828", "foo", "bar")
...to the HTTPPasswordMgrWithDefaultRealm object.
If that password set was added, then the password lookup for
the proxy was successful, and urlopen() worked. If that
password set was not included, then the password lookup for
the proxy was unsuccessful (despite the inclusion of the
other 2, similar, password sets - "http://blah.com:17828";
and "blah.com"), and urlopen() would fail. Hence my
suspicion that the password manager did not fully remove the
scheme, despite attempts to do so.
I'll see if I can set it up on the latest python and get it
to happen again.
Just as an explanation, the situation was that I was running
an authenticating proxy on a non-standard port (in order to
avoid clashing with the normal proxy), in order to test out
how my download code would work through an authenticating proxy.
--
Comment By: John J Lee (jjlee)
Date: 2003-12-01 00:14
Message:
Logged In: YES
user_id=261020
[ python-Bugs-944394 ] No examples or usage docs for urllib2
Bugs item #944394, was opened at 2004-04-29 12:02 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: No examples or usage docs for urllib2 Initial Comment: Hi there, I'm sure I reported this before, but it's a couple of major releases later, and there's still no usage docs for urllib2. The examples given are too trivial to be helpful, but I'm guessing people are using the module so there must be some examples out there somewhere ;-) With a bit o fhelp from Moshez, I found the docstring in the module source. At the very least, it'd be handy if that appeared somewhere at: http://docs.python.org/lib/module-urllib2.html But really, mroe extensive and helpful documentation on this cool new module would be very handy. Chris -- Comment By: John J Lee (jjlee) Date: 2006-04-15 19:49 Message: Logged In: YES user_id=261020 They are here: http://docs.python.org/lib/urllib2-examples.html -- Comment By: Chris Withers (fresh) Date: 2006-04-15 19:07 Message: Logged In: YES user_id=24723 Where are these examples you're referring to? I don't see any at: http://docs.python.org/lib/module-urllib2.html I've already commented that the existing ones in the docstring would be a start but still don't really much help in taking full advantage of this module. -- Comment By: John J Lee (jjlee) Date: 2006-04-15 18:34 Message: Logged In: YES user_id=261020 Examples for urllib2 were added some time ago, so I suggest this bug is closed. -- Comment By: Chris Withers (fresh) Date: 2004-06-01 09:17 Message: Logged In: YES user_id=24723 I'm certainly willing, but I am totally incapable :-S The reason I opened this issue is because it would seem that urllib2 is better the urllib, but seems to be severely underdocumented, and hence I don't understand how to use it and so can't provide examples. As I said in the original submission, including the module's docstring in the Python module documentation would be a start, but doesn't cover what appears to be the full potential of a great module... -- Comment By: Martin v. Löwis (loewis) Date: 2004-05-31 22:15 Message: Logged In: YES user_id=21627 Are you willing to provide examples? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281692 ] urllib violates rfc 959
Bugs item #1281692, was opened at 2005-09-04 18:30 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: urllib violates rfc 959 Initial Comment: [forwarded from http://bugs.debian.org/324023] python's urllib does the following things "on the line" when retrieving a file by ftp: send(3, "PASV\r\n", 6, 0) = 6 send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28 But RFC 959 states: This command [NLST] causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor So, according to the robustness principle, it is wrong that python aborts file transfer if the server refuses to support NLST on files. -- Comment By: John J Lee (jjlee) Date: 2006-04-15 21:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. -- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1357260 reports the same issue for both urllib and urllib2. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-09-08 07:18 Message: Logged In: YES user_id=341410 "The pathname should specify a directory or other system-specific file group descriptor." If the system (ftp server) does not support a particular 'file name' as a 'file group descriptor', it seems to me that the system (ftp server) is braindead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable.
Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. -- Comment By: John J Lee (jjlee) Date: 2006-04-15 21:06 Message: Logged In: YES user_id=261020 Patch 1470976 fixes this bug. -- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:16 Message: Logged In: YES user_id=261020 Bug 1281692 reports the same issue for the urllib case, and includes a reference to the RFC. -- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-17 05:38 Message: Logged In: YES user_id=1033842 File "/usr/lib/python2.4/ftplib.py", line 241, in sendcmd return self.getresp() File "/usr/lib/python2.4/ftplib.py", line 216, in getresp raise error_perm, resp IOError: [Errno ftp error] [Errno ftp error] 550 tompda_685692_Professional.Palm.OS.Programming.part12.rar: No such file or directory. -- Comment By: Thomas Lee (krumms) Date: 2005-11-15 13:34 Message: Logged In: YES user_id=315535 what's the expected response/error code from the FTP server if the NLST fails? -- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 11:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 15:11
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on FreeBSD 4.x
Initial Comment:
$ ./python Lib/test/regrtest.py test_ctypes
test_ctypes
test test_ctypes failed -- Traceback (most recent call
last):
File
"/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py",
line 333, in test_struct_return_2H
self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (-1004, 2123) != (198, 264)
1 test failed:
test_ctypes
[41158 refs]
This is with a subversion checkout updated to 5am AEST
(Aust) 14Apr06, debug build.
The returned tuple values (s2h.x, s2h.y) appear to vary
from run to run, so it looks like something isn't where
its expected.
This is with a FreeBSD 4.8 i386 system (not
particularly recent), using gcc 2.95.4. A quick and
dirty test (in C) suggests that its not an alignment
issue for the 2 shorts in the S2H struct.
Ideas for trying to debug this further?
--
>Comment By: Thomas Heller (theller)
Date: 2006-04-15 22:26
Message:
Logged In: YES
user_id=11105
Committed as 45440.
For NetBSD, this change seems not to be required - ctypes
works fine as it is (I'm testing this on the SF compilefarm
host, which has NetBSD 2.0.2).
--
Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-15 13:18
Message:
Logged In: YES
user_id=250749
Your suggested change does indeed get the test to pass on
this system. Given the history and relationship of
[Free/Net/Open]BSD, I would suggest that for x86 it is very
likely that you will need to add defined(__NetBSD__) clauses
as well.
>From my POV this bug can now be closed.
Thanks, Thomas.
BTW, the actual patch applied was:
--- ffi.c.orig Tue Apr 4 05:26:32 2006
+++ ffi.c Sat Apr 15 21:02:16 2006
@@ -121,7 +121,7 @@
switch (cif->rtype->type)
{
case FFI_TYPE_VOID:
-#if !defined(X86_WIN32) && !defined(__OpenBSD__)
+#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
#endif
case FFI_TYPE_SINT64:
@@ -135,7 +135,7 @@
cif->flags = FFI_TYPE_SINT64;
break;
-#if defined(X86_WIN32) || defined(__OpenBSD__)
+#if defined(X86_WIN32) || defined(__OpenBSD__) ||
defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
if (cif->rtype->size == 1)
{
--
Comment By: Thomas Heller (theller)
Date: 2006-04-14 21:09
Message:
Logged In: YES
user_id=11105
Of course I meant FreeBSD instead of NetBSD, sorry.
--
Comment By: Thomas Heller (theller)
Date: 2006-04-14 21:08
Message:
Logged In: YES
user_id=11105
This looks very similar to a problem I recently 'fixed' on
OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86
the problem seemed to be that small structures are passed
like short or int. You could try to fix it by adding the
appropriate definition in
Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines
138. Maybe changing them to
#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__NetBSD__)
or whatever the magic symbol for Netbsd is.
Unfortunately I do not have access to a netbsd machine myself.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1460514 ] ctypes extension does not compile on Mac OS 10.3.9
Bugs item #1460514, was opened at 2006-03-29 10:28 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Andrew Dalke (dalke) Assigned to: Thomas Heller (theller) Summary: ctypes extension does not compile on Mac OS 10.3.9 Initial Comment: I compiled Python from CVS this morning. It silently failed to compile ctypes. Here is the text surrounding the failure gcc [deleted] -c /Users/dalke/cvses/python-svn/Modules/_ctypes/ libffi/src/powerpc/darwin_closure.S -o build/temp.darwin-7.9.0- Power_Macintosh-2.5/darwin_closure.o darwin_closure.S:249:unknown section attribute: live_support darwin_closure.S:249:Rest of line ignored. 1st junk character valued 69 (E). building 'itertools' extension ... Python installed but when I tried to import ctypes I got File "/usr/local/lib/python2.5/ctypes/__init__.py", line 8, in from _ctypes import Union, Structure, Array ImportError: No module named _ctypes I tracked it down to the '+live_support' attribute from the darwin_closure.S. My compiler does not understand that. Thomas Heller (in private email) pointed out the text from the ctypes README On OS X, the segment attribute live_support must be defined. If your compiler doesn't know about it, upgrade or set the environment variable CCASFLAGS="-Dno_live_support". Upgrading is out of the option. I set the environment variable but that did not fix things when I tried to recompile Python. However, editing the file to remove the "+live_support" works. All the self-tests passed, and my experimentation this afternoon was successful. -- >Comment By: Thomas Heller (theller) Date: 2006-04-15 22:33 Message: Logged In: YES user_id=11105 Thanks for the feedback. For the warnings in Modules/_ctypes/cfield.c, I have no idea what is wrong there. For the warnings in the libffi-sources I tend to ignore them because I don't want to change them too much. For the test-failure: can you find out why this fails? (In the meantime I'm trying to get hold of 10.3 installation disks - any tips how to shrink the only existing partition on my mac mini running 10.4 and setting up a multi-boot system would be appreciated, if anyone wants to help. As an alternative ssh-access to an existing osx installation for testing would of course also help. I don't know if this is feasible or not ;-) -- Comment By: Andrew Dalke (dalke) Date: 2006-04-14 02:51 Message: Logged In: YES user_id=190903 Sorry - was ill and not doing anything for a week. I've built the latest code from SVN. No problems with the compilation and I am able to import just fine. I did get the following compiler warnings /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c: In function `CField_repr': /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:259: warning: signed size_t format, Py_ssize_t arg (arg 3) /Users/dalke/cvses/python-svn/Modules/_ctypes/cfield.c:267: warning: signed size_t format, Py_ssize_t arg (arg 3) /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:383: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:384: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:388: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:389: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:394: warning: function declaration isn't a prototype /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c: In function `ffi_closure_helper_DARWIN': /Users/dalke/cvses/python-svn/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.c:622: warning: unused variable `temp_ld' When I run the self test I get one error FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_ctypes.py", line 12, in test_main() File "Lib/test/test_ctypes.py", line 9, in test_main run_suite(unittest.TestSuite(suites)) File "/Users/dalke/cvses/python-svn/Lib/test/test_support.py", line 285, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/Users/dalke/cvses/python-svn/Lib/ctypes/test/test_loading.py", line 30, in test_load cdll.load(libc_name) File "/Users/dalke/cvses/python-svn/Lib/ctypes/_loader.py", line 1
[ python-Bugs-1470353 ] test_ctypes fails on FreeBSD 4.x
Bugs item #1470353, was opened at 2006-04-14 23:11
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Andrew I MacIntyre (aimacintyre)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on FreeBSD 4.x
Initial Comment:
$ ./python Lib/test/regrtest.py test_ctypes
test_ctypes
test test_ctypes failed -- Traceback (most recent call
last):
File
"/home/andymac/dev/python-svn-head/Lib/ctypes/test/test_functions.py",
line 333, in test_struct_return_2H
self.failUnlessEqual((s2h.x, s2h.y), (99*2, 88*3))
AssertionError: (-1004, 2123) != (198, 264)
1 test failed:
test_ctypes
[41158 refs]
This is with a subversion checkout updated to 5am AEST
(Aust) 14Apr06, debug build.
The returned tuple values (s2h.x, s2h.y) appear to vary
from run to run, so it looks like something isn't where
its expected.
This is with a FreeBSD 4.8 i386 system (not
particularly recent), using gcc 2.95.4. A quick and
dirty test (in C) suggests that its not an alignment
issue for the 2 shorts in the S2H struct.
Ideas for trying to debug this further?
--
>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-16 13:03
Message:
Logged In: YES
user_id=250749
In that case, it would be worth confirming whether later
versions of FreeBSD (at least 5.4, better 6.0) are also
affected. I don't know whether there's anyone from
DragonflyBSD active - its a FreeBSD 4.x offshoot.
--
Comment By: Thomas Heller (theller)
Date: 2006-04-16 06:26
Message:
Logged In: YES
user_id=11105
Committed as 45440.
For NetBSD, this change seems not to be required - ctypes
works fine as it is (I'm testing this on the SF compilefarm
host, which has NetBSD 2.0.2).
--
Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2006-04-15 21:18
Message:
Logged In: YES
user_id=250749
Your suggested change does indeed get the test to pass on
this system. Given the history and relationship of
[Free/Net/Open]BSD, I would suggest that for x86 it is very
likely that you will need to add defined(__NetBSD__) clauses
as well.
>From my POV this bug can now be closed.
Thanks, Thomas.
BTW, the actual patch applied was:
--- ffi.c.orig Tue Apr 4 05:26:32 2006
+++ ffi.c Sat Apr 15 21:02:16 2006
@@ -121,7 +121,7 @@
switch (cif->rtype->type)
{
case FFI_TYPE_VOID:
-#if !defined(X86_WIN32) && !defined(__OpenBSD__)
+#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
#endif
case FFI_TYPE_SINT64:
@@ -135,7 +135,7 @@
cif->flags = FFI_TYPE_SINT64;
break;
-#if defined(X86_WIN32) || defined(__OpenBSD__)
+#if defined(X86_WIN32) || defined(__OpenBSD__) ||
defined(__FreeBSD__)
case FFI_TYPE_STRUCT:
if (cif->rtype->size == 1)
{
--
Comment By: Thomas Heller (theller)
Date: 2006-04-15 05:09
Message:
Logged In: YES
user_id=11105
Of course I meant FreeBSD instead of NetBSD, sorry.
--
Comment By: Thomas Heller (theller)
Date: 2006-04-15 05:08
Message:
Logged In: YES
user_id=11105
This looks very similar to a problem I recently 'fixed' on
OpenBSD - maybe it is even a bug in libffi. On OpenBSD x86
the problem seemed to be that small structures are passed
like short or int. You could try to fix it by adding the
appropriate definition in
Modules/_ctypes/libffi/src/x86/ffi.c, at lines 124 and lines
138. Maybe changing them to
#if !defined(X86_WIN32) && !defined(__OpenBSD__) &&
!defined(__NetBSD__)
or whatever the magic symbol for Netbsd is.
Unfortunately I do not have access to a netbsd machine myself.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470353&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
