New submission from Stefan Krah :
Hello,
in my private repo I've changed memoryview's getbufferproc to be PEP-3118
compliant. test_multiprocessing does the equivalent of the following sequence,
which is not allowed by PEP-3118:
>>> import array, io
>>> a = array.a
Stefan Krah added the comment:
Of course, there is another interpretation:
[PyBUF_FORMAT]
"The returned buffer must have true format information if this flag is
provided. This would be used when the consumer is going to be checking for what
'kind' of data is actually stor
Stefan Krah added the comment:
I've come to think that PyBUF_SIMPLE requests were really intended
as a way of casting contiguous buffers with arbitrary formats to
one-dimensional buffers of unsigned bytes. At least that is what Numpy
does.
Then test_multiprocessing would be correct.
Stefan Krah added the comment:
I think this would be useful and I'll try it out in
features/pep-3118#memoryview.
Syntax options that I'd prefer:
a = array.array('i', [1,2,3])
m = memoryview(a, 'B')
Or go all the way and make memoryview take any flag:
a
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > Or go all the way and make memoryview take any flag:
> >
> > a = array.array('i', [1,2,3])
> > m = memoryview(a, getbuf=PyBUF_SIMPLE)
>
> This is good for testing, but Python developers shou
Stefan Krah added the comment:
Good, I'll use 'format'. I was mainly worried about the shadowing
issue.
--
___
Python tracker
<http://bugs.py
Stefan Krah added the comment:
Rethinking a bit: Casting to arbitrary formats might go a bit far.
Currently, the combination (format=NULL, shape=NULL) can serve as
a warning "This buffer has been cast to unsigned bytes".
If we allow casts from bytes to int32, we'll have (form
Stefan Krah added the comment:
Nick Coghlan wrote:
> So I agree with Victor that 1-D bytes -> any shape/format and any
> shape/format -> 1-D bytes should be allowed, but I think we should
> hold off on allowing arbitrary transformations in a single step.
1-D bytes -> any
New submission from Stefan Krah :
memoryview.tobytes() converts a non-contiguous array to
a contiguous representation. This result is not right:
>>> from numpy import *
>>> x = array([1,2,3,4,5], dtype="B")
>>> y = x[::-1]
>>> y
array([5,
Stefan Krah added the comment:
Antoine Pitrou wrote:
> That's rather funky. What should the right result be?
Basically [5, 4, 3, 2, 1] as bytes:
'\x05\x04\x03\x02\x01'
Looks like an off-by-one error.
I was a bit surprised that tobytes() automatically converts anything
New submission from Stefan Krah :
I've noticed that assumptions about the operand types in tp_richcompare()
are not always consistent. As far as I can see, the first parameter
in tp_richcompare() is guaranteed to be of the correct type.
But in some places the first parameter's typ
New submission from Stefan Krah :
Numpy and PyBuffer_IsContiguous() have different ideas of
C-contiguity if there is a zero in strides (this is allowed,
I asked Pauli Virtanen).
>>> from numpy import *
>>> nd = ndarray(shape=[10], strides=[0])
>>> nd.flags
C_CONTI
New submission from Stefan Krah :
PyCData_NewGetBuffer() must provide strides information if requested,
e.g. in response to a PyBUF_FULL_RO request.
--
assignee: skrah
components: Extension Modules
messages: 143135
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status
Stefan Krah added the comment:
Yes, definitely. I'm going to push a new memoryview implementation
(complete for all 1D/native format cases) in a couple of days.
Once that is done, perhaps we could create a memoryview-struct
branch on top of that.
--
nosy: +
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue12788>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
Hi,
test_urllib fails in refleak mode:
./python -m test -uall -v -R : test_urllib
==
FAIL: test_invalid_redirect (test.test_urllib.urlopen_HttpTests
New submission from Stefan Krah :
stefan@opensolaris:~/hg/cpython$ ./python -m test -uall -v test_ctypes
== CPython 3.3.0a0 (default:5c8b6e03ebfe, Sep 7 2011, 13:41:08) [C]
== Solaris-2.11-i86pc-i386-32bit little-endian
== /export/home/stefan/hg/cpython/build/test_python_28849
Testing with
New submission from Stefan Krah :
Hi, suncc detected pointer arithmetic with a pointer to void:
"./Modules/faulthandler.c", line 910: warning: pointer to void or function used
in arithmetic
"./Modules/faulthandler.c", line 911: warning: pointer to void or function
Stefan Krah added the comment:
Yes, the warning is gone.
--
___
Python tracker
<http://bugs.python.org/issue12929>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
The segfault occurs both with CFUNCTYPE and PYFUNCTYPE in
ffi_prep_incoming_args_SYSV(). I'm not very familiar with
either suncc or the dbx debugger, and I can't get dbx to
step into that function (compiled with -g, libffi is not
stripped as far as
New submission from Stefan Krah :
I'm getting random segfaults in `make buildbottest` on qemu-debian-arm:
Linux-2.6.26-2-versatile-armv5tejl-with-debian-5.0.8 little-endian
The segfaults occurred in test_robotparser and test_nntplib and
couldn't be reproduced when running the tests
Changes by Stefan Krah :
Added file: http://bugs.python.org/file23119/51cedae5acfc.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Here's a completely restructured memoryview implementation that I believe
is quite robust. Both memoryobject.c (the parts I worked on, which is 91%)
and _testbuffer.c have 100% code coverage, including all error conditions [1].
memoryview is tested agains
Stefan Krah added the comment:
Kristján, could you check out the new implementation over at #10181?
I have trouble reproducing a big speed difference between bytearray
and memoryview (Linux, 64-bit). Here are the timings I get for the
current and the new version:
Slicing
---
1) ./python
Stefan Krah added the comment:
The cast method is completely implemented over at #10181.
--
dependencies: +Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
___
Python tracker
<http://bugs.python.org/issue5
Changes by Stefan Krah :
--
dependencies: +Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
> is over 1000x slower that the optimized versions of memoryview.
Oh dear, scratch that. Lets make that 15x. ;)
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
I see. I thought this was mainly about memoryview performance, so
I did not specifically look at bytearray. The poor performance seems
to be Windows specific:
C:\Users\stefan\hg\pep-3118\PCbuild>amd64\python.exe -m timeit -n 1000 -s
"x = ((b'x
Stefan Krah added the comment:
With Stefan Behnel's slice-object-cache.patch, I get this (PEP-3118 branch):
Linux: bytes: 0.097 usec bytearray: 0.127 usec memoryview: 0.12 usec
Windows: bytes: 0.11 usec bytearray: 0,184 usec memoryview: 0.139 usec
On Linux, that's qu
Stefan Krah added the comment:
I still need to understand the full impact of the PEP, but it seems
very sound. I've left two small comments on Rietveld, and there's
an additional question:
Should the input of OSError be checked?
>>> OSError("not an errno", "
New submission from Stefan Behnel :
As is obvious from the code, PyModule_GetDict() can fail if being passed a
non-module object, and when the (unlikely) dict creation at the end fails. The
documentation of the C-API function should be fixed to reflect that, i.e. it
should state that NULL is
New submission from Stefan Behnel :
In Py3, PyCode_New() takes a new argument "kwonlyargcount". The signature
change is not currently in the Py3 C-API documentation.
http://docs.python.org/dev/c-api/code.html
PyCodeObject *
PyCode_New(int argcount, int kwonlyargcount,
i
Stefan Krah added the comment:
No such luck. Somehow gdb doesn't dump the core file:
[ 25/359] test_urllib2_localnet
Fatal Python error: Segmentation fault
Current thread 0x400225f0:
File "/home/user/cpython-e91ad9669c08/Lib/socket.py", line 389 in
create_connection
F
Stefan Krah added the comment:
This is slightly embarrassing: The partition containing the qemu images
was full. I don't encounter this often, so it tends to be the last thing
I think of.
Proudly presenting a core dump. Since the segfault occurs in
libpthread, I suggest we close this. Wh
Stefan Krah added the comment:
Nice debugging work! I compiled --with-system-ffi and there the
issue seems fixed.
Do we have a libffi-3.0.10 release candidate in Modules/_ctypes?
The README says libffi-3.0.10, but the last commit for ffi.c was
17 months ago:
http://hg.python.org/cpython/log
Stefan Krah added the comment:
I left some remarks on Rietveld.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bug
Stefan Krah added the comment:
Traceback with faulthandler disabled:
Core was generated by `./python -m test -uall -r --randseed=8304772'.
Program terminated with signal 11, Segmentation fault.
[New process 3948]
#0 0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
(gdb)
Stefan Krah added the comment:
Curiously enough python *is* built --with-pydebug.
Version 9d658f000419, which is pre-faulthandler, runs without segfaults.
Could faulthandler cause problems like these:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370060
--
nosy: +haypo
Stefan Behnel added the comment:
lxml.etree has encapsulated this in a 'docinfo' property which also holds the
XML 'version', the 'standalone' state and the DOCTYPE (if available).
Note that this information is readily available in lxml.etree for any parsed
El
Stefan Behnel added the comment:
That's why I mention it here to prevent future incompatibilities between the
two libraries.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Issue 8714 could be related as well: On OpenBSD, after a KeyboardInterrupt
one has to hit before the traceback appears.
This was introduced in (or exposed by) r68460. When Python is compiled
without threads, the bug does not occur.
--
nosy: +skrah
Stefan Krah added the comment:
Starting with r82746 in py3k, I'm getting duplicate LDFLAGS in sysconfig:
make distclean
export BASECFLAGS="-ftest-coverage -fprofile-arcs"
export LDFLAGS="-fprofile-arcs"
./configure
make
$ ./python
Python 3.2a0 (py3k:82746M, Aug 16 20
Stefan Krah added the comment:
This is what happens. In the Makefile, I have:
CONFIGURE_LDFLAGS= -fprofile-arcs
PY_LDFLAGS= $(CONFIGURE_LDFLAGS) $(LDFLAGS)
But since LDFLAGS=-fprofile-arcs is in the environment, too, we get the
duplication.
The sysconfig issue is related. In Lib
Stefan Krah added the comment:
Closing as a duplicate of issue 9189.
--
nosy: +skrah
resolution: -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder: -> Improve CFLAGS handling
___
Python tr
Changes by Stefan Krah :
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue1054041>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Behnel added the comment:
Here's a patch against the latest py3k. The following will call the new code,
for example:
str(memoryview(b'abc'), 'ASCII')
whereas bytes and bytesarray continue to use their own special casing code
(which has also changed a bi
Stefan Krah added the comment:
Sridhar, thanks for the information. /usr/bin/which is a shell script
on Linux, too, but it does not source any config files.
I think the behavior is odd, but as you say, it can be worked around.
In the worst case, one can set the PATH in ~/.cshrc to a sane PATH
Stefan Behnel added the comment:
Doesn't the GIL protect the bytearray buffer? Or does decoding free the GIL?
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/i
Stefan Behnel added the comment:
Regardless of the answer, I think Antoine is right, special cases aren't
special enough to break the rules, and this is a special case that's more
safely handled as part of the normal buffer case.
Updated patch uploaded.
--
Added f
Stefan Behnel added the comment:
... and another complete patch that refactors the complete function to make it
clearer what happens. Includes a small code duplication for the bytes object
case, which I think it acceptable.
--
Added file:
http://bugs.python.org/file18588
Changes by Stefan Behnel :
Removed file:
http://bugs.python.org/file18588/unicodeobject-PyUnicode_FromEncodedObject-buffer-refactored.patch
___
Python tracker
<http://bugs.python.org/issue7
Stefan Behnel added the comment:
Another updated patch with a readability fix (replacing the last one).
--
Added file:
http://bugs.python.org/file18589/unicodeobject-PyUnicode_FromEncodedObject-buffer-refactored.patch
___
Python tracker
<h
Stefan Behnel added the comment:
When I read the comments and exception texts in the function, it didn't occur
to me that "char buffer" could have been used as a name for the old Py2 buffer
interface. From the context, it totally makes sense to me that the function
(which
Stefan Krah added the comment:
I think you are closing too aggressively.
Python 3.2a0 (py3k:81783, Jun 6 2010, 16:07:26)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" fo
Stefan Krah added the comment:
The new CFLAGS logic is capable of overriding configure options and
CFLAGS are mentioned in ./configure --help. I think OPT is somewhat
obsolete now, so perhaps this could be closed.
$ make CFLAGS="-O2"
gcc -pthread -c -ftest-coverage -fprofile-arcs -
Changes by Stefan Krah :
--
keywords: -needs review
___
Python tracker
<http://bugs.python.org/issue4594>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Michael Haubenwallner wrote:
> @Stefan: Nope, setting some PATH in ~/.cshrc is the wrong thing to do, and it
> actually is the reason for this issue at all:
> 'which' is intended to tell the location of some command that would be used
> w
New submission from Stefan Krah :
On Windows, the initfunc of a C extension is exported twice, as
seen here:
test_distutils
xxmodule.c
xxmodule.obj : warning LNK4197: export 'initxx' specified multiple times; using
first specification
First export: pyport.h: #define PyMODINIT_FUNC
Stefan Krah added the comment:
Tarek, I forgot to add you, sorry. I was thinking mainly about distutils,
not distutils2.
--
nosy: +tarek
___
Python tracker
<http://bugs.python.org/issue9
Stefan Krah added the comment:
I have a new patch with tests, but I'm not quite satisfied with it.
The remaining problem is that the choice of ml64 or ml is fragile
if a user has executed `vcvarsall xyz`, and we attempt to use the
resulting environment.
For example, if `vcvarsall amd64
Stefan Krah added the comment:
For Visual Studio Express this issue depends on issue 7511.
--
dependencies: +msvc9compiler.py: ValueError: [u'path']
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
> Stefan (sorry for the misattribution in my previous message), can you test
> with 3.2 and 3.1 and adjust versions if needed?
Not easily at the moment. I just noticed that I replaced my only
Express installation with a Pro trial-edition.
Anyon
Stefan Krah added the comment:
I see the same crash in test_capi, qemu, Windows 7, Debug|x64. The
function crash_no_current_thread() introduced in r81142 ultimately
calls Py_FatalError, which then aborts.
--
nosy: +skrah
___
Python tracker
<h
Stefan Krah added the comment:
I just see that the test is running as expected:
_testcapi.crash_no_current_thread() is running in a subprocess, so
the abort() is harmless on Linux. On Windows, abort() causes the
pop-ups, apparently even when it occurs in a subprocess.
Perhaps we should
Stefan Krah added the comment:
The patches are very similar. This one always chooses ml64 on a 64 bit
platform, even when a user has executed `vcvarsall x86`.
The patch in #7546 attempts to honor the environment and has unit tests,
so I'm making #7546 the superseder.
--
resol
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file18681/vcasm2.patch
___
Python tracker
<http://bugs.python.org/issue7546>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Minor cleanups in vcasm2.patch.
--
Added file: http://bugs.python.org/file18742/vcasm2.patch
___
Python tracker
<http://bugs.python.org/issue7
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file18742/vcasm2.patch
___
Python tracker
<http://bugs.python.org/issue7546>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Further cleanup (sorry for the mail volume!).
--
Added file: http://bugs.python.org/file18743/vcasm2.patch
___
Python tracker
<http://bugs.python.org/issue7
Changes by Stefan Krah :
--
nosy: +brian.curtin, sneves, zooko
versions: -Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue7546>
___
___
Stefan Krah added the comment:
Just a short explanation:
In #7384 I used the strict version of the patch for 2.7/3.2 because Thomas
Dickey recommended not to load readline+ncurses and ncursesw
at the same time.
Actually the distros should either link readline against libtinfo
(Fedora) or
New submission from Stefan Behnel :
PySequence_GetSlice() in Objects/abstract.c contains the following code:
mp = s->ob_type->tp_as_mapping;
if (mp->mp_subscript) {
This crashes when the type's "tp_as_mapping" is NULL. The obvious fix is to
simply write
if
Stefan Krah added the comment:
I can reproduce this using the internal (embedded python) of PyScripter
(nice work BTW!).
I can't reproduce it under any other circumstances. The test case
from #9215 runs fine in VS, and also this produces the correct output:
#include
int
main(int argc,
Stefan Krah added the comment:
I wonder if calling _Py_SET_53BIT_PRECISION_START/_Py_SET_53BIT_PRECISION_END
every time will have any measurable effect on performance. First, string
conversions have a lot of overhead already. Then, for compilers that already
set the correct control word, only
Stefan Krah added the comment:
I benchmarked _PyOS_ascii_strtod without the macros, with the macros
and with always calling both fnstcw/fldcw. There is no real difference:
import timeit
s = "str(38210.0)"
t = timeit.Timer(stmt=s)
t.timeit(number=1000)
t.timeit(number=1000
Stefan Krah added the comment:
Mark Dickinson wrote:
> Whoops; that *was* string to float. How about float to string?
These are the results for format_float_short. The first one is quite funny:
If the control word is left as is (64-bit prec on Linux), _Py_dg_dtoa
apparently requires m
Stefan Krah added the comment:
The tracker swallowed some parts of my mail:
In general, execution times for _Py_dg_dtoa vary quite a bit depending on
the number that is converted:
>>> s = "str(1.5e300)"
>>> t = timeit.Timer(stmt=s)
Stefan Krah added the comment:
On an older Celeron platform the differences are up to 7%, but again,
the number that is converted has a far greater impact:
None:
=
>>> s = "str(38210.0)"
>>> t = timeit.Timer(stmt=s)
>>>
>>> t.timeit(number=
Stefan Krah added the comment:
Can you reproduce it by executing this?
>>> format(0.15256118774414062, ".2f")
--
nosy: +skrah
___
Python tracker
<http://bugs
Stefan Krah added the comment:
FreeBSD 5.0 has stdint.h, which includes machine/_stdint.h. In the
latter file the *_MAX constants are defined.
It looks like FreeBSD has had the correct setup for more than 7 years:
http://svn.freebsd.org/viewvc/base/release/5.0.0/sys/i386/include/
I would be
Stefan Krah added the comment:
r85358 fixes the failures in test_sysconfig. The duplicate LDFLAGS are
still present, but if it is generally accepted that make-LDFLAGS should
be appended to configure-LDFLAGS, then I don't see any way around that.
As for me, this could be closed again
New submission from Stefan Krah :
Found by Valgrind:
==3947== Use of uninitialised value of size 8
==3947==at 0x5716D13: _itoa_word (in /lib/libc-2.8.90.so)
==3947==by 0x5719F53: vfprintf (in /lib/libc-2.8.90.so)
==3947==by 0x5743239: vsnprintf (in /lib/libc-2.8.90.so)
==3947
Changes by Stefan Krah :
--
stage: -> patch review
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue10152>
___
___
New submission from Stefan Krah :
Found by Valgrind, patch attached:
==4921== 24 bytes in 1 blocks are definitely lost in loss record 419 of 2,694
==4921==at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4921==by 0x417F06: _PyObject_New (object.c:244)
==4921==by 0x520C4E
Changes by Stefan Krah :
--
components: +Interpreter Core
___
Python tracker
<http://bugs.python.org/issue10152>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I can still reproduce it in py3k just by hitting Ctrl-D in the interactive
interpreter:
$ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python
==16724== Memcheck, a memory error detector
==16724== Copyright (C) 2002-2009, and GNU GPL'
New submission from Stefan Krah :
This is one of two remaining "definitely lost" leaks in py3k. It started
to appear in r70459. How to reproduce:
make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make
valgrind --leak-check=full --suppression
New submission from Stefan Krah :
This is one of two remaining "definitely lost" leaks in py3k. It first
appeared in r70152. How to reproduce:
make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make
valgrind --leak-check=full --suppression
Changes by Stefan Krah :
--
assignee: amaury.forgeotdarc ->
___
Python tracker
<http://bugs.python.org/issue10157>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
I tracked it down to r68683, which is still a large commit.
--
___
Python tracker
<http://bugs.python.org/issue10157>
___
___
Pytho
Stefan Krah added the comment:
To add to the mystery, the leak disappears if the key value is not
interned in PyDict_SetItemString:
Index: Objects/dictobject.c
===
--- Objects/dictobject.c(revision 70459)
+++ Objects
Stefan Krah added the comment:
Marc-Andre Lemburg wrote:
> I'm not sure how you determine what is a leak and what not.
> Interned Unicode objects stay alive until the interpreter
> is finalized.
>
> Are you suggesting that the finalization does not free the
> interned
Stefan Krah added the comment:
I also thought that it might be a pointer that's lost in marshal.c.
However, perhaps a pointer is lost in Py_Finalize. With this ...
Index: Modules/main.c
===
--- Modules/main.c (revision
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file19294/pythonrun.patch
___
Python tracker
<http://bugs.python.org/issue10153>
___
___
Python-bugs-list m
Stefan Krah added the comment:
There is actually a second refleak of the same kind. New patch attached.
--
Added file: http://bugs.python.org/file19326/pythonrun2.patch
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
Hirokazu, the patch looks good to me. Unfortunately Valgrind still
reports the leak.
--
___
Python tracker
<http://bugs.python.org/issue10
Stefan Krah added the comment:
Re disabling interning in PyDict_SetItemString:
A comment in unicodeobject.c says that globals should not be used
before calling _PyUnicode_Init. But in Py_InitializeEx (pythonrun.c)
_PyUnicode_Init is called after _Py_ReadyTypes, _PyFrame_Init,
_PyLong_Init
Stefan Krah added the comment:
I've verified the leak manually. The cause is that global variables in
unicodeobject.c, e.g. free_list, are used before _PyUnicode_Init() is
called. Later on _PyUnicode_Init() sets these variables to NULL, losing
the allocated memory.
Here is an example o
Stefan Krah added the comment:
After taking the scenic route through half of the tree[1], I finally
found another leak in pythonrun.c. I'm closing #10153, merging those
two leaks into the new patch.
Does it look ok?
[1] Valgrind stack traces should be approached with ca
301 - 400 of 4949 matches
Mail list logo
