[ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)
Bugs item #1529269, was opened at 2006-07-26 23:17 Message generated for change (Comment added) made by ostkamp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido Ostkamp (ostkamp) Assigned to: Thomas Heller (theller) Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler) Initial Comment: Hello, as promised here is the second report because of problems with building Python 2.5b2 on Solaris 10 (Sparc). I have been using the GCC this time. These are the problems (for full logs please see attachments): building '_ctypes' extension gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_ctypes/_ctypes.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/ Modules/_ctypes/callbacks.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth on-2.5b2/Modules/_ctypes/callproc.o build/temp.solaris-2.10-sun4us-2.5/home/ostk amp/Python-2.5b2/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-sun4us-2.5/ho me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o build/temp.solaris-2.10-sun4us- 2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o build/temp.solari s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif. o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l ibffi/src/sparc/ffi.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5 b2/Modules/_ctypes/libffi/src/sparc/v8.o build/temp.solaris-2.10-sun4us-2.5/home /ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o -o build/lib.solaris -2.10-sun4us-2.5/_ctypes.so ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedcca5 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccab is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccaf is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccb3 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeeeae06 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeeecaf6 is non-aligned collect2: ld returned 1 exit status building '_curses' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/ home/ostkamp/Python-2.5b2/./Include -I./Include -I. -I/home/ostkamp/Python-2.5b2 /Include -I/home/ostkamp/Python-2.5b2 -c /home/ostkamp/Python-2.5b2/Modules/_cur sesmodule.c -o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu les/_cursesmodule.o /home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In function `PyCursesWindow_ GetStr': /home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822: warning: implicit declar ation of function `mvwgetnstr' gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_cursesmodule.o -lcurses -ltermcap -o build/lib.solaris-2.10-sun4us-2.5/_curses .so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fata l: relocation error: file build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m vwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/ home/ostkamp/Python-2.5b2/./Include -I./Include -I. -I/home/ostkamp/Python-2.5b2 /Include -I/home/ostkamp/Python-2.5b2 -c /home/ostkamp/Python-2.5b2/Modules/_cur ses_panel.c -o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu les/_curses_panel.o gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_curses_panel.o -lpanel -lcurses -ltermcap -o build/lib.solaris-2.10-sun4us-2.5 /_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses running build_scripts Regards, Guido -- >Comment By: Guido Ostkamp (ostkamp) Date: 2006-07-28 13:28 Message: Logged In: YES user_id=1028306 @theller: I have tried --with-pydebug, but it gives the same errors. Please find logfile attached. @nnorwitz: I remove the Python-2.5b2 directory and
[ python-Bugs-1530382 ] ssl object documentation lacks a couple of methods
Bugs item #1530382, was opened at 2006-07-28 15:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530382&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lawrence Oluyede (rhymes) Assigned to: Nobody/Anonymous (nobody) Summary: ssl object documentation lacks a couple of methods Initial Comment: According to http://docs.python.org/dev/lib/ssl-objects.html the SSL Objects expose only write() and read() but they also expose issuer() and server() methods. See Modueles/_ssl.c from line 557 to 565 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530382&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521491 ] file.seek() influelce write() when opened with a+ mode
Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by rudnik_lior
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&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 Interpreter Core
Group: Python 2.5
>Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode
Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"
Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):
from __future__ import with_statement
with open(path,'a+') as f:
f.seek(0,2) # go to end
pos = f.tell()
f.seek(0,0)
line = f.readline().strip()
f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
f.write("something")
Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)
--
>Comment By: Lior (rudnik_lior)
Date: 2006-07-28 13:35
Message:
Logged In: YES
user_id=1364480
This issue is on windows XP.
Wasnt tested on other versions (only 2.5b1 and b2)
I expect the code to always write at the end according to
the documentation. However if I user file seek (opend as A+)
to read from begining of the file, the write also goes to
begining of file.
Note - in the code snippet, please remove the last
f.seek(0,2) to see the problem! (it should have been in a
comment)
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-13 07:43
Message:
Logged In: YES
user_id=849994
I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 06:29
Message:
Logged In: YES
user_id=33168
This seems to work for me on Linux. Maybe we are testing
differently. What o/s and version are you using? Does this
work with Python 2.4? Can you attach a complete test case
that demonstrates this problem?
Thanks.
--
Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09
Message:
Logged In: YES
user_id=1364480
Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1525866 ] Bug in shutil.copytree on Windows
Bugs item #1525866, was opened at 2006-07-20 13:00
Message generated for change (Comment added) made by mjfoord
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows
Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably. It will fail always on Windows, since
os.utime does not work on directories.
I guess that a patch similar to this one should fix it:
Index: shutil.py
===
--- shutil.py (Revision 50710)
+++ shutil.py (Arbeitskopie)
@@ -127,7 +127,12 @@
# continue with other files
except Error, err:
errors.extend(err.args[0])
-copystat(src, dst)
+try:
+copystat(src, dst)
+except WindowsError:
+pass
+except OSError, err:
+errors.extend(err.args[0])
if errors:
raise Error, errors
--
>Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 14:09
Message:
Logged In: YES
user_id=1123892
The following should work as a test method for shutil.copytree
(Passes on my box against a patched version of shutil)
def test_copytree_simple(self):
src_dir = tempfile.mkdtemp()
dst_dir = os.path.join(tempfile.mkdtemp(),
'destination')
open(os.path.join(src_dir, 'test.txt'),
'w').write('123')
os.mkdir(os.path.join(src_dir, 'test_dir'))
open(os.path.join(src_dir, 'test_dir', 'test.txt'),
'w').write('456')
#
def testStat(src, dst):
st_src = os.stat(src)
st_dst = os.stat(dst)
if hasattr(os, 'utime'):
self.assertEqual((st_src.st_atime,
st_src.st_mtime), (st_dst.st_atime, st_dst.st_mtime))
if hasattr(os, 'chmod'):
# Should be equal anyway, should we change
permissions on one of the source files ?
self.assertEqual(stat.S_IMODE(st_src.st_mode),
stat.S_IMODE(st_dst.st_mode))
#
try:
shutil.copytree(src_dir, dst_dir)
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test.txt')))
self.assertTrue(os.path.isdir(os.path.join(dst_dir,
'test_dir')))
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test_dir', 'test.txt')))
self.assertEqual(open(os.path.join(dst_dir,
'test.txt')).read(), '123')
self.assertEqual(open(os.path.join(dst_dir,
'test_dir', 'test.txt')).read(), '456')
finally:
try:
os.remove(os.path.join(src_dir, 'test.txt'))
os.remove(os.path.join(dst_dir, 'test.txt'))
os.remove(os.path.join(src_dir, 'test_dir',
'test.txt'))
os.remove(os.path.join(dst_dir, 'test_dir',
'test.txt'))
os.removedirs(src_dir)
os.removedirs(dst_dir)
except:
pass
Can turn the above into a patch tonight if needed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-20 16:14
Message:
Logged In: YES
user_id=21627
Can you also come up with a patch to the test suite?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1525866 ] Bug in shutil.copytree on Windows
Bugs item #1525866, was opened at 2006-07-20 13:00
Message generated for change (Comment added) made by mjfoord
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Foord (mjfoord)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in shutil.copytree on Windows
Initial Comment:
The problem is that the call to 'copystat(src, dst)'
was added to the shutil.copytree function, in svn
r38363 probably. It will fail always on Windows, since
os.utime does not work on directories.
I guess that a patch similar to this one should fix it:
Index: shutil.py
===
--- shutil.py (Revision 50710)
+++ shutil.py (Arbeitskopie)
@@ -127,7 +127,12 @@
# continue with other files
except Error, err:
errors.extend(err.args[0])
-copystat(src, dst)
+try:
+copystat(src, dst)
+except WindowsError:
+pass
+except OSError, err:
+errors.extend(err.args[0])
if errors:
raise Error, errors
--
>Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 14:14
Message:
Logged In: YES
user_id=1123892
Nope - not quite right. Will fix tonight and upload a proper
patch.
Michael
--
Comment By: Mike Foord (mjfoord)
Date: 2006-07-28 14:09
Message:
Logged In: YES
user_id=1123892
The following should work as a test method for shutil.copytree
(Passes on my box against a patched version of shutil)
def test_copytree_simple(self):
src_dir = tempfile.mkdtemp()
dst_dir = os.path.join(tempfile.mkdtemp(),
'destination')
open(os.path.join(src_dir, 'test.txt'),
'w').write('123')
os.mkdir(os.path.join(src_dir, 'test_dir'))
open(os.path.join(src_dir, 'test_dir', 'test.txt'),
'w').write('456')
#
def testStat(src, dst):
st_src = os.stat(src)
st_dst = os.stat(dst)
if hasattr(os, 'utime'):
self.assertEqual((st_src.st_atime,
st_src.st_mtime), (st_dst.st_atime, st_dst.st_mtime))
if hasattr(os, 'chmod'):
# Should be equal anyway, should we change
permissions on one of the source files ?
self.assertEqual(stat.S_IMODE(st_src.st_mode),
stat.S_IMODE(st_dst.st_mode))
#
try:
shutil.copytree(src_dir, dst_dir)
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test.txt')))
self.assertTrue(os.path.isdir(os.path.join(dst_dir,
'test_dir')))
self.assertTrue(os.path.isfile(os.path.join(dst_dir,
'test_dir', 'test.txt')))
self.assertEqual(open(os.path.join(dst_dir,
'test.txt')).read(), '123')
self.assertEqual(open(os.path.join(dst_dir,
'test_dir', 'test.txt')).read(), '456')
finally:
try:
os.remove(os.path.join(src_dir, 'test.txt'))
os.remove(os.path.join(dst_dir, 'test.txt'))
os.remove(os.path.join(src_dir, 'test_dir',
'test.txt'))
os.remove(os.path.join(dst_dir, 'test_dir',
'test.txt'))
os.removedirs(src_dir)
os.removedirs(dst_dir)
except:
pass
Can turn the above into a patch tonight if needed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-20 16:14
Message:
Logged In: YES
user_id=21627
Can you also come up with a patch to the test suite?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525866&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1515471 ] wrong handling of character buffers in stringobject
Bugs item #1515471, was opened at 2006-07-01 02:41
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Georg Brandl (gbrandl)
Assigned to: Fredrik Lundh (effbot)
Summary: wrong handling of character buffers in stringobject
Initial Comment:
stringobject.c:
In string_replace, there is
if (PyString_Check(from)) {
/* Can this be made a '!check' after the Unicode
check? */
}
#ifdef Py_USING_UNICODE
if (PyUnicode_Check(from))
return PyUnicode_Replace((PyObject *)self,
from, to, count);
#endif
else if (PyObject_AsCharBuffer(from, &tmp_s, &tmp_len))
return NULL;
[the same check with "to"]
return (PyObject *)replace((PyStringObject *) self,
(PyStringObject *) from,
(PyStringObject *) to, count);
This is not correct if from or to isn't a string
object, but a char buffer compatible object.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1515471&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1523610 ] PyArg_ParseTupleAndKeywords potential core dump
Bugs item #1523610, was opened at 2006-07-16 19:23
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&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 Interpreter Core
Group: Python 2.4
Status: Pending
Resolution: Fixed
>Priority: 8
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTupleAndKeywords potential core dump
Initial Comment:
After getting bit by bug 893549, I was noticing that
sometimes I was getting a core dump instead of a
TypeError when PyArg_ParseTupleAndKeywords was skipping
over a type the "skipitem" code does not understand.
There are about 4 problems I will describe (though they
are related, so it's probably not worth filing seperate
bugs).
The problem is that the "levels" variable is passed to
the seterror function uninitialized. If levels does
not happen to contain any 0 elements, then the
iteration code in seterror will go crazy (I will get to
this in a moment).
In the one place where "skipitem" is called, you will
notice it immediately calls seterror() if it returned
an error message. However, "levels" is not set by the
skipitem function, and thus seterror iterates over an
uninitialized value. I suggest setting levels[0] = 0
somewhere in the beginning of the code, since the
expectations of setting the "levels" seems awefully
delicate.
(As a side note, there's no bounds checking on the
levels variable, either. It seems unlikely that
someone will have 32 levels of nested variables, but I
think it points to a general problem with how the
variable is passed around.)
A second fix is to set levels[0] = 0 if setitem fails
before calling seterror().
Now, returning to the "seterror goes crazy" problem I
mentioned earlier, the following code in the seterror
function:
while (levels[i] > 0 && (int)(p-buf) < 220) {
should be:
while (levels[i] > 0 && (int)(p-buf) > 220) {
At least, that's what I'm assuming it is supposed to
be. I think it should be clear why this is bad.
But wait, there's more! The snprintf in seterror call
uses the incorrect size of buf. The following line:
PyOS_snprintf(p, sizeof(buf) - (buf - p),
should be:
PyOS_snprintf(p, sizeof(buf) - (p - buf),
My particular platform (FreeBSD) puts a NUL character
at the end of the buffer. However, since the size of
the buffer is computed incorrectly, this line of code
stomps on the stack (overwritting the levels value in
my case).
Let me know if you have any questions, or want any
sample code.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-26 01:04
Message:
Logged In: YES
user_id=849994
Fixed the "levels[0] = 0" and the "p-buf" issue in rev.
50843. Still waiting for input on python-dev about the
levels overflow, though I think it can be ignored.
--
Comment By: Eric Huss (ehuss)
Date: 2006-07-16 19:28
Message:
Logged In: YES
user_id=393416
Oops, skip the section about <220 being >220. I've been
staring at it too long. The rest of the issues should be
valid, though.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- >Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469557 ] FTP modue functions are not re-entrant, give odd exceptions
Bugs item #1469557, was opened at 2006-04-12 17:13
Message generated for change (Comment added) made by brucepeterson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&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: Closed
Resolution: Invalid
Priority: 5
Submitted By: brucepeterson (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions
Initial Comment:
If I define a class using the Thread and FTP moudles,
start a process which gathers FTP responses,
additional calls to the class may have the responses
of the thread instead of the main loop (or vice versa)
This causes weird and unexpected exceptions from the
ftplib.
For instance I get the following error when the
thread process does a pwd() function
error_reply: 213 34603008
The "213" reply is a response from the main process
size() function
-
Code
-
from time import sleep
from threading import Thread
class ftpMachine(Thread, ftplib.FTP):
def __init__(self, svr, user, passwd):
Thread.__init__(self)
ftplib.FTP.__init__(self, svr, user, passwd)
def run(self):
for x in xrange(20):
output="Thread -"+str(self.nlst())[:30]
print output
sleep (0.0100)
def main():
aCon = ftpMachine("LocalFTP", "user", "")
aCon.start()
for x in xrange(20):
output = "Main -- " + str(aCon.size("File"))
print output
sleep (0.010)
Workround:
Rewrite code to create a third worker thread for
response isolation? Don't know that this would solve
the problem.
---
Exception example
---
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "dualFTPIssue.py", line 17, in run
output = "Thread output " + str(self.nlst())[:30]
+" ..."
File "C:\Python24\lib\ftplib.py", line 448, in nlst
self.retrlines(cmd, files.append)
File "C:\Python24\lib\ftplib.py", line 396, in
retrlines
conn = self.transfercmd(cmd)
File "C:\Python24\lib\ftplib.py", line 345, in
transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "C:\Python24\lib\ftplib.py", line 321, in
ntransfercmd
host, port = self.makepasv()
File "C:\Python24\lib\ftplib.py", line 299, in
makepasv
host, port = parse227(self.sendcmd('PASV'))
File "C:\Python24\lib\ftplib.py", line 566, in
parse227
raise error_reply, resp
error_reply: 213 34603008
--
>Comment By: brucepeterson (brucepeterson)
Date: 2006-07-28 10:02
Message:
Logged In: YES
user_id=1500983
I am running on a unit that limits the FTP connections to 4
high bandwidth connections and normally uses a passive FTP
transfer.
The response from the passive FTP transfer could come at
any time. Also, by inspection, the FTP module throws an
exception when an unexpected reply happens. So when I'm
querrying the size of the clip on the destination and
instead get a transfer complete message from the passive
FTP session, that transfer complete message causes the
exception.
To "fix" this issue would requre that when the FTP
message queue is read, that pending requests (passive
transfers) would be considered before returning immediate
command responses (cwd, ls, size, etc.). If I get a couple
of days, I may rewrite the functions that read the FTP
responses and submit the changes for consideration.
For my current project, I have decided not to querry the
transfer to see if it completes, but instead to do a simple
wait before sending the next transfer.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-27 23:26
Message:
Logged In: YES
user_id=580910
I don't understand why you cannot use two connection resources. Are you
running in a severely resource constrained environment?
Anyway, what you're doing right now is undefined behaviour. Unless explicitly
stated otherwise classes in the stdlib aren't fully reentrant. You will
therefore
have to arrange some kind of exclusion mechanism. One way of doing that is
to introduce a lock (probably wrapping the FTP client instead of using
multiple inheritance in the progress). Another way it to introduce a 3th thread
that performs the actual FTP operations and communicate with that using a
queue. Please ask around on python-list/comp.lang.python if you need help
with this.
BTW. I didn't close this bug, although I do understand why it was closed: the
behaviour you describe isn't a bug but expected behaviour.
--
[ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert
Bugs item #1530559, was opened at 2006-07-28 18:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.pack raises TypeError where it used to convert
Initial Comment:
[EMAIL PROTECTED]:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
[EMAIL PROTECTED]:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'
This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1441072 ] No simple example for pickle
Feature Requests item #1441072, was opened at 2006-03-01 16:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1441072&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: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: No simple example for pickle
Initial Comment:
The docs for pickle lack a simple example of typical
usage. The Example page has only an advanced example. I
suggest something like this be added to the Usage or
Examples page:
Here is a simple example that shows how to use pickle
to save and restore a dictionary:
>>> import pickle
>>> data = dict(a=1, b=2, c=[3,4,5], d='cheese')
>>> f=open('data.pickle', 'wb')
>>> pickle.dump(data, f)
>>> f.close()
>>>
>>> f=open('data.pickle', 'rb')
>>> data2=pickle.load(f)
>>> f.close()
>>> data2
{'a': 1, 'c': [3, 4, 5], 'b': 2, 'd': 'cheese'}
Kent
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:10
Message:
Logged In: YES
user_id=849994
A simple example was added by Andrew in rev. 50903.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1441072&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1527597 ] New module: miniconf
Feature Requests item #1527597, was opened at 2006-07-24 03:43 Message generated for change (Comment added) made by syfou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&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: 3 Submitted By: S.Fourmanoit (syfou) Assigned to: Nobody/Anonymous (nobody) Summary: New module: miniconf Initial Comment: Find enclosed a new data persistence module: miniconf, that basically allows the casual creation and reading of configuration files and similar simple data sets. I ended-up using part of this code in many projects I did in Python (such as adesklets), and many other fellow developers borrowed it from me, so I though it could be nice to have it as a part of the standard library. So I cleaned it up, re-factored it as a simple, standalone module, and here it is, complete with documentation and its test module. Find enclosed a patch against svn trunck (Python 2.5b2, revision 50794). It changes nothing to the tree, besides adding a one-liner to Doc/lib/lib.tex to reference the new documentation. The module also works untouched on Python 2.4.3; I will be glad to provide a patch against any other tree if you want me too; all comments are of course welcomed. -- >Comment By: S.Fourmanoit (syfou) Date: 2006-07-28 14:48 Message: Logged In: YES user_id=1175491 Updated patch, based on feedback from Armin Rigo. Also distributed on the Python Cheese Shop as module version 1.2.0: http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.2.0 -- Comment By: S.Fourmanoit (syfou) Date: 2006-07-27 01:57 Message: Logged In: YES user_id=1175491 Updated patch, based on feedback from David Hopwood and Phillip J. Eby. Also distributed on the Python Cheese Shop as module version 1.1.0: =http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.1.0 -- Comment By: S.Fourmanoit (syfou) Date: 2006-07-25 02:20 Message: Logged In: YES user_id=1175491 Current miniconf entry on the Python Cheese Shop: http://cheeseshop.python.org/pypi?:action=display&name=miniconf&version=1.0.1 Thanks for your diligent feedback so far; I will send a short message to python-dev tomorrow. -- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 15:55 Message: Logged In: YES user_id=849994 You'll at least have to raise this on the python-dev list. It is most probable that you're then asked to let a user base grow by making the module available e.g. via Cheese Shop and report back at a time where 2.6 is nearing. -- Comment By: S.Fourmanoit (syfou) Date: 2006-07-24 12:44 Message: Logged In: YES user_id=1175491 > Have you published this on the Python Cheese Shop? If did not; without being trivial, I felt this was both generic and useful enough to be worth the inclusion into the base library; I managed to miss the feature freeze on python 2.5 -- sorry about that... I don't mind submitting it to the Python Cheese Shop, if it is the right track to have it eventually committed to Python code base; miniconf having virtually no collateral impact on the rest of the code, it is indeed perfectly suitable for distribution as a standalone module for both the 2.4.x and incoming 2.5.x Python interpreters. I don't mind either waiting for the end of the feature freeze, keeping the module up to date as needed against any new code. I am foreign to the development cycle of Python -- do you know what will be the next window of opportunity? Into the incoming 2.5 tree when it will be out of the freeze? Into python 2.6? -- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 09:39 Message: Logged In: YES user_id=849994 Have you published this on the Python Cheese Shop? This might be the more appropriate way to make this module known to other Python developers since there's no way to include it in 2.5 any more. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1527597&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert
Bugs item #1530559, was opened at 2006-07-28 18:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
>Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert
Initial Comment:
[EMAIL PROTECTED]:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
[EMAIL PROTECTED]:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'
This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:51
Message:
Logged In: YES
user_id=849994
Bob?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521491 ] file.seek() influelce write() when opened with a+ mode
Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
>Assigned to: Tim Peters (tim_one)
Summary: file.seek() influelce write() when opened with a+ mode
Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"
Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):
from __future__ import with_statement
with open(path,'a+') as f:
f.seek(0,2) # go to end
pos = f.tell()
f.seek(0,0)
line = f.readline().strip()
f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
f.write("something")
Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:54
Message:
Logged In: YES
user_id=849994
Perhaps you can try in on Windows, Tim...
--
Comment By: Lior (rudnik_lior)
Date: 2006-07-28 13:35
Message:
Logged In: YES
user_id=1364480
This issue is on windows XP.
Wasnt tested on other versions (only 2.5b1 and b2)
I expect the code to always write at the end according to
the documentation. However if I user file seek (opend as A+)
to read from begining of the file, the write also goes to
begining of file.
Note - in the code snippet, please remove the last
f.seek(0,2) to see the problem! (it should have been in a
comment)
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-13 07:43
Message:
Logged In: YES
user_id=849994
I also cannot see any problem with the above code and can
append to a file indefinitely. What exactly are you
expecting the code to do, and what do you get? Which OS is this?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-13 06:29
Message:
Logged In: YES
user_id=33168
This seems to work for me on Linux. Maybe we are testing
differently. What o/s and version are you using? Does this
work with Python 2.4? Can you attach a complete test case
that demonstrates this problem?
Thanks.
--
Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09
Message:
Logged In: YES
user_id=1364480
Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert
Bugs item #1530559, was opened at 2006-07-28 14:07
Message generated for change (Comment added) made by etrepum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert
Initial Comment:
[EMAIL PROTECTED]:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
[EMAIL PROTECTED]:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'
This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.
--
>Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 15:31
Message:
Logged In: YES
user_id=139309
That wasn't really intentional, but the old behavior looks a bit suspect:
$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'
We could change it to check for floats and do a DeprecationWarning?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 14:51
Message:
Logged In: YES
user_id=849994
Bob?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert
Bugs item #1530559, was opened at 2006-07-28 18:07
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert
Initial Comment:
[EMAIL PROTECTED]:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
[EMAIL PROTECTED]:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'
This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 19:44
Message:
Logged In: YES
user_id=849994
I think that's a question for python-dev.
--
Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 19:31
Message:
Logged In: YES
user_id=139309
That wasn't really intentional, but the old behavior looks a bit suspect:
$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'
We could change it to check for floats and do a DeprecationWarning?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 18:51
Message:
Logged In: YES
user_id=849994
Bob?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530448 ] ctypes build fails on Solaris 10
Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip -- >Comment By: Skip Montanaro (montanaro) Date: 2006-07-28 17:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S -- Comment By: Thomas Heller (theller) Date: 2006-07-28 11:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1529871 ] distutils regression related to Distribution.run_command
Bugs item #1529871, was opened at 2006-07-27 17:49
Message generated for change (Comment added) made by pje
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529871&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.5
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Collin Winter (collinwinter)
Assigned to: Phillip J. Eby (pje)
Summary: distutils regression related to Distribution.run_command
Initial Comment:
The following used to work in Python 2.4.x but fails
under Python 2.5:
>>> import setuptools
>>> import distutils.core
>>> distutils.core._setup_stop_after = 'config'
>>>
>>> import setup
>>> setup.dist.run_command('test')
Where setup.dist is an instance of
distutils.core.Distribution (which setuptools replaces
with setuptools.dist.Distribution).
Under Python 2.4.x, this code would execute setuptools'
test command. Under Python 2.5b2 (as of r50855), this
code results in the following exception:
/opt/dev/python/2.5/lib/python2.5/distutils/dist.py:263:
UserWarning: Unknown distribution option: 'test_suite'
warnings.warn(msg)
Traceback (most recent call last):
File "test.py", line 8, in
setup.dist.run_command('test')
File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 992, in run_command
cmd_obj = self.get_command_obj(command)
File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 868, in get_command_obj
klass = self.get_command_class(command)
File
"/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools/dist.py",
line 357, in get_command_class
return _Distribution.get_command_class(self, command)
File
"/opt/dev/python/2.5/lib/python2.5/distutils/dist.py",
line 851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'test'
I'd greatly appreciate it if this regression could be
fixed before Python 2.5 is released.
--
>Comment By: Phillip J. Eby (pje)
Date: 2006-07-28 22:04
Message:
Logged In: YES
user_id=56214
Fixed in r50916 on the trunk.
--
Comment By: Phillip J. Eby (pje)
Date: 2006-07-28 04:53
Message:
Logged In: YES
user_id=56214
Um, why is there a py2.4 egg on your python 2.5 path?
Setuptools configures itself according to the Python version
it is built with, so a 2.4 egg is not going to be correctly
configured for 2.5. I don't know if this is related to your
problem or not, but I was unable to reproduce your problem
with a setuptools 0.7a1 checkout. I was only able to
reproduce it with setuptools 0.6.
--
Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 22:12
Message:
Logged In: YES
user_id=1344176
I've tried using setuptools 0.7a1 in conjunction with Python
2.5b2 (r50877), and the problem still exists. setuptools'
extension commands still do not work (tested: rotate, alias,
egg_info, bdist_egg, test), that is, 'python2.5 setup.py
test' still fails with "error: invalid command 'test'".
Also, the code snippet in the bug report does not work. I am
sure Python is picking up setuptools 0.7a1 because the path
/opt/dev/python/2.5/lib/python2.5/site-packages/setuptools-0.7a1dev_r50755-py2.4.egg/setuptools/dist.py
appears in the traceback.
--
Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 21:13
Message:
Logged In: YES
user_id=56214
Problem source confirmed: reverting the PEP 302 breakage of
r46372 (need-for-speed import cache hack) fixes the problem.
setuptools 0.7a1 doesn't show any problems because it uses
2.5's "pkgutil" module if possible, and r46372 patches
pkgutil in a way that masks the problem, at least as far as
setuptools is concerned, for this one specific feature.
(Other code in setuptools is affected in both 0.6 *and* 0.7,
and will require further workaround code to be written.)
--
Comment By: Phillip J. Eby (pje)
Date: 2006-07-27 18:35
Message:
Logged In: YES
user_id=56214
I can't reproduce this using setuptools 0.7a1 and the Python
2.5 trunk. Please note that setuptools 0.6 does *not*
support Python 2.5; there were numerous changes needed and
there may still be additional changes needed. Please try
using setuptools 0.7a1 and let me know what you find out.
Thanks.
--
Comment By: Collin Winter (collinwinter)
Date: 2006-07-27 18:34
Message:
Logged In: YES
user_id=1344176
Further testing reveals that all of setuptools' extension
commands (tested: egg_info, bdist_egg, test, ro
[ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert
Bugs item #1530559, was opened at 2006-07-28 11:07
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&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.5
Status: Open
Resolution: None
>Priority: 9
Submitted By: Joe Wreschnig (piman)
Assigned to: Bob Ippolito (etrepum)
Summary: struct.pack raises TypeError where it used to convert
Initial Comment:
[EMAIL PROTECTED]:~$ python2.4 -c "import struct;
struct.pack('>H', 1.0)"
[EMAIL PROTECTED]:~$ python2.5 -c "import struct;
struct.pack('>H', 1.0)"
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
TypeError: unsupported operand type(s) for &: 'float'
and 'long'
This might have appeared as part of the struct
optimizations; if struct isn't going to convert anymore
for performance reasons, I think this should be
mentioned in the release notes. Though personally I
would prefer struct go back to converting its arguments.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-28 20:21
Message:
Logged In: YES
user_id=33168
I'd like to see a deprecation warning so old code continues
to work. struct is way to loose and needs to be tightened
up, but that might not fully happen until py3k.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 12:44
Message:
Logged In: YES
user_id=849994
I think that's a question for python-dev.
--
Comment By: Bob Ippolito (etrepum)
Date: 2006-07-28 12:31
Message:
Logged In: YES
user_id=139309
That wasn't really intentional, but the old behavior looks a bit suspect:
$ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))"
'\x00\x01'
We could change it to check for floats and do a DeprecationWarning?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-07-28 11:51
Message:
Logged In: YES
user_id=849994
Bob?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1530012 ] Literal strings use BS as octal escape character
Bugs item #1530012, was opened at 2006-07-27 15:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&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 Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: brucepeterson (brucepeterson) Assigned to: Nobody/Anonymous (nobody) Summary: Literal strings use BS as octal escape character Initial Comment: Also in 2.4 Using a literal to hard code a path. My directory happened to start with a number and I couldn't open the file due to the bad directory name. Found that the tripple quote was operating as documented. I would have at least expected the tripple double quotes to not have an escape character. (Is this a pep?) (From my reading of the Introduction, the triple double quotes should act like a raw string except that you can have a single double quote included in the string.) - code snippet: - dir1 = """C:\1stDirecotry""" dir2 = '''C:\2ndDirecotry''' dir3 = '''C:\9thDirecotry''' print dir1, dir2, dir3 C:☺stDirecotry C:☻ndDirecotry C:\9thDirecotry dir1's format was not expected, dir2's format might be expected. >>> '''\1''' '\x01' >>> '''\9''' '\\9' -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-28 20:25 Message: Logged In: YES user_id=33168 Triple quotes are just like single or double quotes wrt escaping. You need to prefix the string with an r: r"C:\1stDirecotry" to get what you want. This is probably documented in many places. I'm not sure where you looked or where you expected it to be documented. Can you suggest improvements? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
