Stefan Krah added the comment:
STINNER Victor wrote:
> Hum, this issue is a regression from Python 3.2.
>
> Python 3.2.3+ (3.2:243ad1a6f638+, Aug 4 2012, 01:36:41)
> [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
> >>> import array
> >>> a=array.ar
Stefan Krah added the comment:
Also, it was suggested that 'u' should be deprecated:
http://mail.python.org/pipermail/python-dev/2012-March/117392.html
Personally, I don't have an opinion on that; I don't use the 'u'
format code.
Nick, could you have a lo
Stefan Krah added the comment:
Of course, if two formats *are* the same, it is possible to use
memcmp(). I'll work on a patch.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
> Did you see attached patch array_unicode_format.patch? It uses struct
> format "H" or "I" depending on the size of wchar_t.
I totally overlooked that. Given that memoryview can be fixed to
compare buffers with unknown formats, I don&
Stefan Krah added the comment:
I have a patch already for the unknown format codes in memoryview.
Currently fighting (as usual) with the case explosions in the tests.
I think I can have a full patch by next weekend.
--
___
Python tracker
<h
New submission from Stefan Krah:
Continuing the discussion from #13072. I hit a snag here:
Determining in full generality whether two format strings describe
identical items is pretty complicated, see also #3132.
I'm attaching a best effort fmtcmp() function that should do the
foll
Stefan Krah added the comment:
Installing dpkg-dev indeed resolved the issue for me on Debian Wheezy,
but msg166444 said that the problem appeared in 7955d769fdf5.
So was dpkg-dev already an official dependency before 7955d769fdf5
or not?
--
nosy: +skrah
Stefan Krah added the comment:
With ma.diff from #11715 dpkg-dev is indeed not required (checked
on Wheezy).
--
___
Python tracker
<http://bugs.python.org/issue14
New submission from Stefan Krah:
Running *any* test of the test suite currently produces a bus error
on Debian sparc [http://people.debian.org/~aurel32/qemu/sparc/].
After the bus error, the tests seem to proceed normally though.
This is definitely new. I've been testing memoryview fo
Stefan Krah added the comment:
Setting to critical: debian-sparc 32-bit is apparently deprecated
since Lenny and still uses linuxthreads.
Tracking down the failure could end up in finding a platform bug
like in #12936.
--
priority: release blocker -> criti
Stefan Krah added the comment:
Right, byte order specifiers are always at the beginning of the string.
That is at least something. I wonder if we should tighten PEP-3118 to
demand a canonical form of format strings, such as (probably incomplete):
- Whitespace is disallowed.
- Except for &#
Stefan Krah added the comment:
I think I've identified one legit Python bug. This is from a *different*
traceback, i.e. the traceback in my first message is still unresolved.
A bus error occurs in test_capi, test_skipitem with format 'D':
Python/getargs.c:782
Py_comp
Stefan Krah added the comment:
Floris, the traceback in my first message only occurs in the
optimized regular build with -O3. Did you try that, too?
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Larry Hastings wrote:
> Attached is a patch attempting to force double alignment. Stefan: please
> apply and try it. Does this help?
Yes, this works nicely.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
As for the original error: in test_subprocess basically every test
fails. With the standard regrtest.py (faulthandler enabled), most
tests generate a bus error in subprocess_fork_exec():
621 cwd_obj2 = NULL;
(gdb)
624 pid = fork(); <-
Stefan Krah added the comment:
> 329 tests OK.
> 7 tests failed:
> test_cmd_line test_exceptions test_ipaddress test_os test_raise
> test_socket test_traceback
Thanks. A lot of these appear to be big-endian related, see #15597.
--
__
Stefan Krah added the comment:
> Removing 3.1, since its addition was apparently done by mistake.
I'm unable to set 2.7 and 3.2 in my browser without also setting
3.1 (using the Shift key to mark multiple fields).
--
___
Python tracke
Stefan Krah added the comment:
The buildbot is running inside kvm on a heavily loaded machine. Perhaps
some timeout is too low.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
> If disabling faulthandler avoids new issues, you can add 'if
> [not] sys.thread_info.version.startswith("linuxthreads")'
That suppresses some bus errors. However, they still occur without
being raised (some print statements and a WI
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Could you try to run the tests manually after having upped said timeouts?
> (look for "sleep" in the test file)
No luck there: The tests pass unmodified (100 times wi
Stefan Krah added the comment:
> I can easily provide a specification that makes the current implementation
> "correct"
Yes, the current specification is: memoryview only attempts to
compare arrays with known (single character native) formats and
returns "not equal"
Stefan Krah added the comment:
PEP-3118 specifies strongly typed multi-dimensional arrays. The existing
code in the 3.2 memoryview as well as numerous comments by Travis Oliphant
make it clear that these capabilities were intended from the start for
memoryview as well.
Perhaps the name
Stefan Krah added the comment:
> 1. what does it mean that the formats of v and w are equal?
I'm using array and Py_buffer interchangeably since a Py_buffer struct
actually describes a multi-dimensional array. v and w are Py_buffer
structs.
So v.format must equal w.format, where for
Changes by Stefan Krah :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue15573>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
The ideal specification is:
1) Arrays v and w are equal iff format and shape are equal and for all valid
indices allowed by shape
memcmp((char *)PyBuffer_GetPointer(v, indices),
(char *)PyBuffer_GetPointer(w, indices),
itemsize
Stefan Krah added the comment:
Martin v. Loewis wrote:
> Sure: someone would have to make a proposal what exactly that is.
> IMO, the 3.2 definition *was* simple, but apparently it was considered
> too simple.
It was simply broken in multiple ways. Example:
>>> from nu
Stefan Krah added the comment:
You have rejected the PEP-3118 'u' and 'w' specifiers here:
http://mail.python.org/pipermail/python-dev/2012-March/117390.html
Otherwise, memoryview follows the existing struct module syntax:
http://docs.python.org/dev/library/struct.html#fo
Changes by Stefan Krah :
--
title: memoryview.to_list() incorrect for 'c' format -> struct module 'c'
specifier does not follow PEP-3118
___
Python tracker
<http://
Stefan Krah added the comment:
Martin v. L??wis wrote:
> It's unfortunate that PEP 3118 deviates from the struct module, however,
> memoryview is based onthe buffer interface,and its formatcodes ought to
> conform to the PEP, not to the struct module (IMO).
The struct module
Stefan Krah added the comment:
Martin v. L??wis wrote:
> That the struct module hasn't been updated to support the PEP 3118 is
> already reported as issue 3132, please don't confuse the issues.
> This issue is about memoryview.
No, it isn't. It was always planned
Changes by Stefan Krah :
--
dependencies: +implement PEP 3118 struct changes
title: memoryview.to_list() incorrect for 'c' format -> struct module 'c'
specifier does not follow PEP-3118
___
Python tracker
<http://
Stefan Krah added the comment:
So we have two competing proposals:
1) Py_buffers are strongly typed arrays in the ML sense (e.g. array of float,
array of int).
This is probably what I'd prefer on the C level, imagine a function like
function like PyBuffer_Compare(v, w).
Back
Stefan Krah added the comment:
With -F -j16 I get these failures both on FreeBSD and Linux, but not
the original failure:
==
FAIL: test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests
Stefan Krah added the comment:
Martin v. L??wis wrote:
> Here is a more formal definition of my last proposal,
>
> v and w are equal iff
> v.shape() == w.shape() and
> ((v.format == w.format and v.tobytes() == w.tobytes()) or
>v.tolist() == w.tolist())
> if tolist ra
Stefan Krah added the comment:
To be specific, after a quick look the only function from _testbuffer.c
that would be needed is unpack_single(). This really does not look very
complex.
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Closing since the remaining issue is almost certainly a platform bug.
--
keywords: -3.2regression, patch
resolution: -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed
___
Pytho
Stefan Krah added the comment:
Thanks, Nick. I'll work on a struct module patch then. At this point for me
this is the only satisfying solution.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I'm almost done with my (second) self-review of mpdecimal.c. The only
functions missing are all Karatsuba functions and mpd_qpowmod().
If there are any takers, I would be very happy. For the Karatsuba functions
you'll probably need Roman Maeder's
New submission from Stefan Krah:
With the -R option, test_buffer.py needs an additional warm-up for
the unicode_latin1 cache. Patch attached.
--
components: Tests
files: warm_latin1_cache.diff
keywords: patch
messages: 168063
nosy: skrah
priority: normal
severity: normal
stage: patch
Stefan Krah added the comment:
I'm attaching a test case. You're right, in test_buffer it's
hard to reproduce but I've encountered the "leak" several times
in the past months.
Today I realized that the "leak" always occurred with format code
'c&
Stefan Krah added the comment:
Should we go all the way and also explicitly fill the small int cache?
Integers 0-255 should be initialized already, but I'm not sure
about [-5..-1] and 256. I haven't been able to create a test case
for integers though.
--
Added
Stefan Krah added the comment:
Here is a patch implementing by-value comparisons for all format strings
understood by the struct module. It is slightly longer than promised, since
for larger arrays it is necessary to cache an unpacking object for acceptable
performance. The fast path for
Stefan Krah added the comment:
I didn't get my own comments as mail, so this is just a notification that I've
answered Nick's comments.
--
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
Here is a new patch that hopefully addresses all comments.
--
Added file: http://bugs.python.org/file26831/issue15573-struct-2.diff
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Nick's comment in msg167963 got me thinking. Indeed, in Numpy the 'U'
specifier is similar to the struct module's 's' format code, only for
UCS4. So I'm questioning whether the current semantics of 'u' and 'w&
Stefan Krah added the comment:
Martin v. Loewis wrote:
> I would be fine with deprecating the 'u' type arrays, acknowledging
> that the Py_UNICODE element type is even more useless now than before.
> If that is done, there is no point in fixing anything about it. If
> i
Stefan Krah added the comment:
Well, apparently people do use 'u', see #15035.
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
This one should be fixed by #13072. Could you check again?
--
___
Python tracker
<http://bugs.python.org/issue15035>
___
___
Pytho
Stefan Krah added the comment:
Martin v. L??wis wrote:
> #15035 indicates that there is a need for UCS-2 arrays, using 'u' arrays was
> technically incorrect, since it is based on Py_UNICODE, whereas the API in
> question uses UniChar (which apparently is a two-byte type).
Stefan Krah added the comment:
There is still one corner case involving NaNs: Released memoryviews always
compare equal. I took that over from the 3.2 implementation.
>>> import array
>>> a = array.array('d', [float('nan')])
>>> m = memoryview(a)
&
Stefan Krah added the comment:
Reproduced by another FreeBSD bot:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/238/steps/test/logs/stdio
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Thank you for the patch and the big amount of work that you are doing on so
many modules!
I'm afraid though that the patch is not acceptable in its current state:
1) The unit tests do not pass. This could be fixed.
2) The patch slows down _decimal
Changes by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<http://bugs.python.org/issue15722>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
I tried to benchmark this patch but I'm getting a segfault:
Python 3.3.0b2+ (default:dc18d73e67a5, Aug 18 2012, 15:37:04)
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more info
Changes by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<http://bugs.python.org/issue15672>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
Thanks, Mark. With your change applied I can't measure any performance
differences either.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
The test suite is not a good benchmark: it also tests decimal.py. For
numerical performance I'm running:
cd Modules/_decimal/tests
../../../python bench.py
You can hit Ctrl-C after the first cdecimal result, since that's usually
already a p
Stefan Krah added the comment:
> What specific decimal test is failing?
# Attributes cannot be deleted
for attr in ['prec', 'Emax', 'Emin', 'rounding', 'capitals', 'clamp',
'flags', 'traps']
Stefan Krah added the comment:
If everyone agrees on deprecating 'u', here's a patch. I think
that should be sufficient to close this issue (unless we absolutely
need deprecation warnings).
--
Added file: http://bugs.python.org/file26892/array_d
Stefan Krah added the comment:
I think issue15573-struct-2.diff is ready to go and I'd rather commit
sooner than later. Nick, can I interpret your last review comment
as "go ahead"? :)
--
___
Python tracker
<http://bugs.pyt
New submission from Stefan Krah:
There are a couple of places in the memoryview docs that still
need a "versionchanged" tag.
Other places might need explanations what exactly has changed.
--
assignee: docs@python
components: Documentation
messages: 168563
nosy: docs@pyt
Stefan Krah added the comment:
Right. I'm tracking all "versionchanged" issues in #15724.
--
___
Python tracker
<http://bugs.python.org/issue15573>
___
__
Stefan Krah added the comment:
The patch looks good in every detail. +1 for committing.
--
___
Python tracker
<http://bugs.python.org/issue15544>
___
___
Pytho
Stefan Krah added the comment:
Since actual removal is only scheduled for 4.0, I think user warnings
can wait until 3.4.
By then, we should have sorted out the struct format codes. In this
scenario we would be sort of forced to use 'C', 'U' and 'W' as the
new
New submission from Stefan Krah:
Coverity found a leak in PyUnicode_AsWideCharString(). Patch attached.
--
components: Interpreter Core
files: aswidechar-leak.diff
keywords: patch
messages: 168584
nosy: haypo, skrah
priority: normal
severity: normal
stage: patch review
status: open
Stefan Krah added the comment:
Thanks!
--
___
Python tracker
<http://bugs.python.org/issue15728>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah:
Coverity found an unchecked return value in _PySequence_BytesToCharpArray().
Patch attached.
A demonstration:
import _posixsubprocess
class Z(object):
def __len__(self):
return 1
_posixsubprocess.fork_exec(1,Z(),3,[1, 2
Stefan Krah added the comment:
Thanks for reviewing!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah:
A Py_ssize_t overflow can be constructed in _PySequence_BytesToCharpArray().
Patch attached.
Demonstration (requires revision >= 2af78f8a98e1):
Python 3.3.0b2+ (default:2af78f8a98e1, Aug 20 2012, 11:38:54)
[GCC 4.4.3] on linux
Type "help"
New submission from Stefan Krah:
There's a use of an unchecked return value in zipimport.c. Patch attached.
--
components: Extension Modules
files: zipimport_null_dereference.diff
keywords: patch
messages: 168644
nosy: skrah
priority: normal
severity: normal
stage: patch review
s
New submission from Stefan Krah:
Coverity found a missing NULL check in subprocess_fork_exec(). Patch attached.
Demonstration:
import _posixsubprocess
class Z(object):
def __len__(self):
return 1
_posixsubprocess.fork_exec(Z(),[b'1'],3,[1,
2],5,6,7,8,9,10,11,12,13,1
Stefan Krah added the comment:
Thanks again!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2
___
Python tracker
<http://bugs.python.or
New submission from Stefan Krah:
Coverity found a missing NULL check in builtin_compile(). Patch attached.
--
components: Interpreter Core
files: builtin-compile-check-null.diff
keywords: patch
messages: 168664
nosy: skrah
priority: normal
severity: normal
stage: patch review
status
Stefan Krah added the comment:
issue15736.diff shows what I meant in the comments. I find this
slightly more readable than casting the big RHS expression.
--
Added file: http://bugs.python.org/file26931/issue15632.diff
___
Python tracker
<h
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file26931/issue15632.diff
___
Python tracker
<http://bugs.python.org/issue15736>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Sorry, the right diff this time.
--
Added file: http://bugs.python.org/file26932/issue15736.diff
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
Thanks, done.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Thanks for the warning. I see you've already committed, so my natural
inertia has protected me from additional merge work. :)
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Bad news: gcc-4.6.3 needs the size_t cast, otherwise it warns with
both the assert() and the (argc < 0) version.
So I suggest using the size_t cast and a comment.
--
___
Python tracker
<http://bugs.pyth
Stefan Krah added the comment:
I used the cast for gcc >= 4.6 and the assert() as a courtesy to
authors of buggy sq_length() functions. Thanks for the comments!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open
Stefan Krah added the comment:
Looks like a ZFS/nanosecond issue. My FreeBSD buildbot uses FFS and does not
have the failures.
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
> So, looks like FreeBSD's /usr/share/mk/sys.mk is to blame here.
> It unconditionally sets CFLAGS to `-O2 -pipe`.
I've been debugging this once, too. My conclusion was that if the OS is set up
that way, we shouldn't do anything about it in t
Stefan Krah added the comment:
The timeouts on NetBSD and OpenBSD are very likely related to
bugs in the user-space thread libraries. See also #8714.
I would recommend running these bots --without-threads.
--
nosy: +skrah
___
Python tracker
<h
Stefan Krah added the comment:
Thanks, fixed.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
I agree with Mark's arguments. Yesterday I tried to use as_decimal() in
a small program and it did not feel natural to me. I'll probably continue
to use Decimal(f.numerator) / f.denominator.
If this goes in, I'd prefer that as_decimal() always uses
Stefan Krah added the comment:
Good, I think this can be closed then.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
The effect of the change is pretty minimal though: Previously
"not equal" was returned for unknown formats, now the struct
module figures it out.
memoryobject.c has 100% coverage except for a couple of lines
that are either impossible to reach or ve
Stefan Krah added the comment:
> You can look at the attached memoryobject.c.gcov: *All* failure paths
> are taken since Python API functions are wrapped in macros that
> set PyExc_FailAPIError and return failure at predefined points
> the test suite.
That should read: With a patc
Stefan Krah added the comment:
Great, give me 20 minutes or so.
--
___
Python tracker
<http://bugs.python.org/issue15573>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Except for Misc/NEWS the patch can be committed unchanged. Please
go ahead!
[The remaining doc changes are tracked elsewhere.]
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from Stefan Krah:
test_parallel_module_init() fails on Windows-64:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/553/steps/test/logs/stdio
==
FAIL: test_parallel_module_init
Stefan Krah added the comment:
The buildbot in question uses -j4, and I can reproduce this on Linux
with:
./python -m test -uall -F -j4 -v test_threaded_import
==
FAIL: test_parallel_meta_path
Stefan Krah added the comment:
I completely forgot about that issue. The patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue15765>
___
___
Stefan Krah added the comment:
I agree that for 3.2 this isn't so important given that non-contiguous
arrays have multiple issues there.
Christian, does a fix for 3.2 benefit FreeImage? Don't you run into
other problems with memoryview?
If it helps, I can try to write a pat
Stefan Krah added the comment:
I can only reproduce this on a Core i7. Native OS is Debian Wheezy,
also reproduced earlier on a FreeBSD VM hosted on that machine
(see msg167989). The machine has 4 physical cores, perhaps we
can blame hyper-threading. ;)
$ cat /proc/cpuinfo | grep "model
Stefan Krah added the comment:
This was less work than expected. I suppose docs can always go in
even after rc1 is out, so I'll wait for that.
--
keywords: +patch
Added file: http://bugs.python.org/file26994/issue15724.diff
___
Python tracker
Stefan Krah added the comment:
I can also reproduce it on the Core 2 machine with a ridiculuously
low switch interval:
diff --git a/Lib/test/regrtest.py b/Lib/test/regrtest.py
--- a/Lib/test/regrtest.py
+++ b/Lib/test/regrtest.py
@@ -198,6 +198,8 @@
except ImportError:
multiprocessing
Stefan Krah added the comment:
Oh, and as usual, my machines have all CPUs at 100% load.
--
___
Python tracker
<http://bugs.python.org/issue15781>
___
___
Pytho
Stefan Krah added the comment:
The feature is undocumented though. Is it a regression?
There are other places as well. The topic was raised in msg153447 and
msg153506, with no further comments. So I concluded that None argument
support wasn't impo
1601 - 1700 of 3396 matches
Mail list logo
