Stefan Krah added the comment:
On Mon, Oct 23, 2017 at 05:16:53PM +, STINNER Victor wrote:
> Memory allocated by PyMem_AlignedAlloc() must be freed with
> PyMem_AlignedFree().
>
> We cannot reuse PyMem_Free(). On Windows, PyMem_AlignedAlloc() is implemented
> with _aligned
Stefan Krah added the comment:
On Mon, Oct 23, 2017 at 09:16:08PM +, Antoine Pitrou wrote:
> > The Arrow memory format for example recommends 64 bit alignment.
>
> I presume you mean 64 bytes?
Yes, I was typing too fast.
--
___
Py
Stefan Krah added the comment:
[me]
> This weakens my use case somewhat [...]
I looked at Victor's patch, and thanks to the alignment <= ALIGNMENT
optimization it seems that always using the aligned_alloc() and
aligned_free() versions for a specific pointer is fast. Nice!
So I
Stefan Krah added the comment:
Since we have "#define PYMEM_FUNCS PYOBJ_FUNCS", I think extensions that
use PyMem_Malloc() also won't get the glibc max_align_t alignment.
But guess technically they should.
--
nosy: +skrah
___
Python
Stefan Krah added the comment:
> In Python 3.7, should we also add the "aligned alloc" requirement?
Linux, BSD, OSX, MSVC should be covered. According to Stackoverflow
MinGW has an internal function.
Android, I don't know. Xavier?
---
Stefan Krah added the comment:
Should we care about the C11 restriction?
http://en.cppreference.com/w/c/memory/aligned_alloc
"size - number of bytes to allocate. An integral multiple of alignment"
posix_memalign and _aligned_malloc don't care about the multiple.
On the o
Stefan Krah added the comment:
> The ways we've discussed using aligned allocation in numpy wouldn't follow
> this requirement without special checking. Which isn't necessarily a big
> deal, and numpy won't necessarily use this API anyway. But I would suggest
>
Stefan Krah added the comment:
> realloc() must not touch the original buffer on failure
I don't understand this: If realloc() fails, the original buffer
is perfectly valid.
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org
Stefan Krah added the comment:
Ah sorry, you mean it cannot write the special bytes.
--
___
Python tracker
<https://bugs.python.org/issue31626>
___
___
Python-bug
Stefan Krah added the comment:
Also, does this occur in a VM on on the bare metal or both?
What leaves me puzzled is that I cannot reproduce the Linux x86 report
with almost the exact same compiler. But I'm on x64 and use -m32.
--
___
P
Stefan Krah added the comment:
Same as #7442, I think.
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue31900>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
On Tue, Oct 31, 2017 at 02:55:04PM +, Nathaniel Smith wrote:
> 3) also it's not clear what the best approach will look like, given that we
> care a lot about using calloc when possible, and have reason to prefer using
> regular freeing func
New submission from Stefan Krah :
This is related to #27987 and #20064 and perhaps the pymalloc patch
from #18835.
I think PyMem_Malloc() should guarantee alignof(max_align_t).
It actually did before the "#define PYMEM_FUNCS PYOBJ_FUNCS" optimization,
so we have a sort of regre
Change by Stefan Krah :
--
nosy: +haypo
___
Python tracker
<https://bugs.python.org/issue31912>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
> Do you mean the C++ std::max_align_t? Does C99 have something like that?
>
> The Linux malloc() manual page says:
>
> "The malloc() and calloc() functions return a pointer to the allocated
> memory, which is suitably aligned for a
Stefan Krah added the comment:
So the big mystery is still:
https://mail.python.org/pipermail/python-dev/2017-October/149880.html
Could be a Linux router with some alternative libc ...
--
___
Python tracker
<https://bugs.python.org/issue31
Stefan Krah added the comment:
On Tue, Oct 31, 2017 at 07:32:00PM +, Serhiy Storchaka wrote:
> >>From 4 considered results the tests are failed on gcc 4.2.1, 4.7.2, 4.8.5,
> >>but are passes on gcc 7.2.0. I suppose this is gcc or libc bug fixed in
> >>recent v
Stefan Krah added the comment:
> For large allocations, you'll probably be better off implementing your own
> aligned allocator on top of calloc than implementing your own calloc on top
> of an aligned allocator. (It's O(1) overhead versus O(n).) And once you're
>
Stefan Krah added the comment:
On Wed, Nov 01, 2017 at 06:17:44PM +, Mark Dickinson wrote:
> I'm really reluctant to (even conditionally) skip the test, because it's
> doing exactly what it's designed to do, namely detecting and reporting that
> Python is giv
Stefan Krah added the comment:
Yes, it may be better not to add it.
To summarize the problems again:
- C11 aligned_alloc() / free() would be more comfortable but isn't
available on MSVC.
- posix_memalign() performance isn't that great.
Stefan Krah added the comment:
> I'm not sure that the cost of the memory allocator itself defeats the gain of
> aligned memory on algorithms. I expect data processing to be much more
> expensive than the memory allocation, no?
I guess this issue isn't easy to focus due
Change by Stefan Krah :
--
nosy: +jyrkih
___
Python tracker
<https://bugs.python.org/issue31932>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Krah :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> setup.py cannot find vcversall.bat on MSWin 8.1 if installed in
user AppData
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
Berker's latest patch looks good to me.
Unrelated to the patch (same before and after), this looks odd to me:
>>> import uuid
>>> uuid._has_uuid_generate_time_safe is None
True
>>>
>>> import _uuid
>>> _uuid.h
Stefan Krah added the comment:
It looks like guaranteed ordered literals are going to happen (yay!):
https://mail.python.org/pipermail/python-dev/2017-November/150144.html
--
nosy: +skrah
resolution: later -> out of date
stage: -> resolved
status: open -> cl
Stefan Krah added the comment:
Just adding +1.
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue31983>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
On Wed, Nov 08, 2017 at 08:28:10PM +, Serhiy Storchaka wrote:
> Does this check work? I tried similar checks with other functions and they
> were falsely passed because calling an undeclared function is not an error in
> C.
Not here. If
Change by Stefan Krah :
--
nosy: +skrah
stage: -> needs patch
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue28789>
___
___
Pyth
Stefan Krah added the comment:
More info:
==22845== Warning: invalid file descriptor 1024 in syscall close()
==22845==at 0x4E493F0: __close_nocancel (syscall-template.S:81)
==22845==by 0xF0BAA74: _close_open_fds_safe (_posixsubprocess.c:297)
==22845==by 0xF0BADF6: child_exec
Stefan Krah added the comment:
Okay, it is probably this:
https://bugs.kde.org/show_bug.cgi?id=331311
The question is whether we should add a suppression or a perhaps
a comment in _posixsubprocess.c
--
nosy: +gregory.p.smith
___
Python tracker
Stefan Krah added the comment:
I think "ambiguous" is not the right word. If a single argument
can be a non-parenthesized generator and all arguments can be
followed by a trailing comma, it's clear.
The language spec is often behind in my experience.
Stefan Krah added the comment:
I would prefer to do nothing about the subject of this issue. I still
don't see any ambiguity, except in a very broad colloquial sense.
Why introduce another special case?
--
___
Python tracker
&
Stefan Krah added the comment:
On Tue, Nov 14, 2017 at 01:31:52PM +, Nick Coghlan wrote:
> If limited to the original scope, this isn't a new special case, it's fixing
> a bug in the implementation of the existing special case (where it's ignoring
> the trailing co
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue32012>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Yes Sir!
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue32012>
___
___
Python-bugs-list mailing list
Unsub
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue32012>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue31983>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Seefeld :
I'm trying to mix positional and non-positional arguments with a script using
`argparse`, but I observe inconsistent behaviour.
The attached test runs fine when invoked with
test_argparse.py --info a a=b
test_argparse.py a a=b --info
but produces the
Stefan Seefeld added the comment:
On 15.11.2017 12:54, R. David Murray wrote:
> Can you reproduce this without your PosArgsParser?
I can indeed (by simply commenting out the `action` argument to the
`add_argument()` calls).
That obviously results in all positional arguments being accumulated
Stefan Seefeld added the comment:
It looks like https://bugs.python.org/issue14191 is a conversation about the
same inconsistent behaviour. It is set to "fixed". Can you comment on this ?
Should I follow the advice mentioned there about how to work around
Change by Stefan Krah :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> TabError behavior doesn't match documentation
___
Python tracker
<https://bugs.p
Stefan Krah added the comment:
I'm now in the camp of forbidding tabs. When I wrote my own parser a couple of
years ago, I tested it on a huge body of Python files that were present on my
system. Tabs always looked accidental.
Is there any *known* code base that deliberately uses
Stefan Krah added the comment:
python-dev is becoming insufferable.
--
___
Python tracker
<https://bugs.python.org/issue24260>
___
___
Python-bugs-list mailin
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue24260>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Tim has mentioned the high quality of fdlibm, and indeed I cannot
reproduce the issue:
wget -r http://www.netlib.org/fdlibm/
Then build libm with or without optimizations, with or without -m32,
gcc or clang.
Then compile a C program that calls tan
Stefan Krah added the comment:
I found an unused i386 box with OpenBSD and Linux (so no VM):
A C program with tan(1.5707963267948961) is wrong on both systems.
fdlibm (directly from netlib.org) is correct on both systems.
Both OS versions are relatively old, so I cannot file an upstream
Stefan Krah added the comment:
At some point linking explicitly against libm was added. The build
still worked until 8acaa31eec removed detect_math_libs().
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue32
Stefan Krah added the comment:
I suggest to restore the logic from 75c0d4f6bb97e723adc3a03c0ff6aaaee0c6981a .
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Stefan Krah :
--
pull_requests: +4642
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32233>
___
___
Python-bugs-list mai
Stefan Krah added the comment:
New changeset bd4ed77f73d37df325fc8f1e193b3ce6bc08094d by Stefan Krah in branch
'master':
bpo-32233: Fix build with --with-system-libmpdec. (#4739)
https://github.com/python/cpython/commit/bd4ed77f73d37df325fc8f1e193b3c
Change by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> compile error
___
Python tracker
<https://bugs.pyt
Stefan Krah added the comment:
This is known and was deliberate when I wrote the module. The list contains
conditions that trigger the exception.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> decimal C module's exception
Stefan Krah added the comment:
Python lists don't implement extended slices, try numpy arrays:
>>> import numpy as np
>>> x = array([[1,2,3], [4,5,6]])
>>> x[:, 2]
array([3, 6])
>>>
>>> lst = [[1,2,3], [4,5,6]]
>>> lst[:, 2]
Tracebac
Stefan Krah added the comment:
I see the first issue now and I agree that Python behaves strangely.
Numpy
=
>>> x = array([1,2,3])
>>> x[1:2] = [1,2,3,4,5]
Traceback (most recent call last):
File "", line 1, in
ValueError: cannot copy sequence with size 5 to
Stefan Krah added the comment:
Okay, the different meanings of "extended slicing" seem to be an old
problem:
https://mail.python.org/pipermail/tutor/2007-July/055838.html
I assumed it referred to numpy's tuple indexing syntax, but it is
apparently also used for referring to th
Stefan Krah added the comment:
Thanks, David, you are of course right! -- I've worked so much with fixed
arrays in the past year that Python's behavior seemed odd and unfathomable. :-)
[Numpy arrays can't adopt that behavior, because growing them would be
Stefan Behnel added the comment:
Seems ok from Cython side. Could be a bit difficult to make an actual use of
this, but at least it shouldn't break anything. And it's a reasonable
constraint to enforce.
--
___
Python track
New submission from Stefan Pochmann :
The itertools page https://docs.python.org/3.6/library/itertools.html says
"Combinatoric generators:" above the table with product(), permutations(), etc.
But as far as I understand, they're not generators and they don't produce
ge
New submission from Stefan Nordhausen :
The following code reproducibly segfaults in version 2.7.13, 3.6.3 and the
current git master (3.7.0a3+):
code = "42 if True else 43\n" * 20
compile(code, "foobar", "exec")
This issue was originally found becau
Stefan Krah added the comment:
> Does it makes sense to have the presence of "global a" in g, block all
> possibility for h, to access it's grand parent's a ?
>From the perspective of ML-style languages with pure lexical scoping, no, it
>does not make sense.
Stefan Nordhausen added the comment:
I tried out PR 3015 of Serhiy and this fixes the segfaults. So it seems to be a
duplicate.
As for backporting the fix: Is this a 'reliable' segfault (i.e. it always
segfaults when the limit is exceeded) or could there be some silent data
corr
Stefan Krah added the comment:
I guess I'd vote for closing this, because the first Google result for "no
binding for nonlocal" on Stackoverflow is quite clear.
The ideal message would be "'a' cannot be both global and nonlocal", but
it would probably compl
Change by Stefan Nordhausen :
--
nosy: +snordhausen
___
Python tracker
<https://bugs.python.org/issue31113>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Okay, I have never used something like that. Personally, I'd
disallow the global statement in g() if 'a' is local in f().
>>> a = 10
>>> def f():
... a = 20
... def g():
... global a
... print(a)
Stefan Krah added the comment:
> Stefan, your last example is formally speaking OK, if one reads the
> "Execution model" literally. The original example is however too
+ambiguous, so it is good that it triggers an error.
OK yes -- desirable, no. IMO execution models are not a
Stefan Krah added the comment:
Because in the example in msg308683 true lexical scoping should,
when processing g()'s name space, search for the name 'a' in the
lexically closest scope f(), find it there and conclude that
'
Stefan Krah added the comment:
You can access globals, but not through another nested scope
where the global name is shadowed.
I have to excuse myself from this discussion. It's interesting,
but I don't have enough bandwidth.
--
___
Pyth
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue32361>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Behnel added the comment:
I also consider it an actual feature of ElementTree to allow arbitrary objects
as its tags, even if it's not one of the most prominent. lxml cannot copy this
because it is based on C libraries internally, but that shouldn't prevent ET
from allowin
Stefan Behnel added the comment:
>That said, I personally question the implementation decision to
>represent things like treating comments as an Element with a tag of a
>Comment function.
This is not going to change.
--
___
Python tracke
Stefan Krah added the comment:
I have just worked on PEP-3118 ==> Datashape translation and I have
encountered many issues similar to the ones in the PR referenced by
Allan.
It seems to me that we should simplify the PEP-3118 struct syntax as much
as possible in order to remove
Change by Stefan Krah :
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue26746>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
I'm sorry if this interrupts the discussion, but isn't this
https://github.com/plures/xnd/blob/06f6dd82dda9c7bca5df30b121b5cd75c6337609/python/xnd/pyxnd.h#L103
of the form package.module.capsule?
This works, and I just want to make sure it continue
Stefan Krah added the comment:
Ah, Serhiy stated the reason (module already imported) previously. Sorry for
the noise.
--
___
Python tracker
<https://bugs.python.org/issue32
Stefan Behnel added the comment:
Sorry, but you are proposing an API extension here that provides no benefits
but duplicates existing functionality in a less versatile place. This is not
going to happen.
The second proposal (str(xml)) is actually not very helpful as it does not
allow any
Stefan Behnel added the comment:
I'd second the proposal of considering the "array.array" type for this, instead
of the bytes/bytearray types. Why? Because it is somewhat of a niche case after
all, and the bytes type seems too exposed for it. Also, array.array supports
more di
Stefan Behnel added the comment:
Nice, I really like this.
Apart from the usual bit of minor style issues, I couldn't see anything
inherently wrong with the PR, but I'll leave the detailed reviews to those
who'd have to maintain the code in the future. :)
-
Stefan Behnel added the comment:
Regarding the benchmarks, just to be sure, did you try reversing the run order
to make sure you don't get unfair caching effects for the later runs?
--
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
On Wed, May 30, 2018 at 10:34:01PM +, STINNER Victor wrote:
> Fatal Python error: Segmentation fault
> Current thread 0x2b52f7326400 (most recent call first):
>
> Is it a bug in the _decimal module?
These kinds of errors are often complete
Stefan Krah added the comment:
How would #33627 support the theory that this is a bug in _decimal? As I read
it, #33627 is in test_complex, which supports the "unrelated random" theory.
--
___
Python tracker
<https://bugs.python.o
Stefan Krah added the comment:
Could you please show how tp_clear() can be called when self->exports > 0? It
should not happen.
#33622 is a big issue with many commits. Would it be possible to extract the
relevant part?
--
nosy: +
Stefan Krah added the comment:
This looks the same as #25525. I think it cannot happen, and no one has ever
reported an actual issue for 6 years now.
You *really* need to show a reproducer if you assert that something can crash.
--
___
Python
Stefan Krah added the comment:
Yes, but who calls tp_clear() if the memoryview is not being deallocated?
--
___
Python tracker
<https://bugs.python.org/issue33
Stefan Krah added the comment:
The point is that *no garbage collection is triggered* if self->exports > 0.
It would be a major bug if it were and I suspect it would be reported within a
week. Fortunately, no such bug has been reported in 6
Stefan Krah added the comment:
Good luck finding it then, Victor.
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue33627>
___
___
Python-bug
Stefan Krah added the comment:
Well, the example would need exports:
>>> a = [bytes()]
>>> a.append(memoryview(a[0]))
>>> a.append(memoryview(a[1]))
>>> a.append(a)
>>> a
[b'', , , [...]]
The first memoryview has one export, so its r
Stefan Krah added the comment:
Well yes, I still want to understand tp_clear(). :)
The docs are a bit vague.
--
___
Python tracker
<https://bugs.python.org/issue33
Stefan Krah added the comment:
test_datetime passes here with nearly identical conditions as on the CI (Ubuntu
14.04, clang, same random seed):
Using random seed 987845
Run tests in parallel using 4 child processes
0:00:01 load avg: 1.70 [ 1/415] test_html passed
0:00:01 load avg: 1.88 [ 2
Stefan Krah added the comment:
A wild theory: Because of the new pervasive includes
(-I/home/travis/multissl/openssl/1.1.0h/include -O3
-I/home/travis/multissl/openssl/1.1.0h/include) some module picks up a wrong
header.
But I just rebuilt https://travis-ci.org/python/cpython/jobs
Stefan Krah added the comment:
I think the tests are order-dependent in multiple places. Personally, I don't
see much value in fixing that because it has little effect on the actual code.
--
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
The test is insignificant. The real tests are mpdecimal-testit- 2.4.1.tar.gz
(http://www.bytereef.org/mpdecimal/download.html), deccheck.py and my private
python test suite.
This test uses the global context that has been modified somewhere. I think I
added
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +6982
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33750>
___
___
Py
Stefan Krah added the comment:
The thread local context was modified in test_round(), so prec=28 was used in
test_from_tuple() when running the whole test suite but prec=9 when running the
single test.
I don't really consider that a bug, but it is easy to "fix".
I wouldn&#x
Stefan Krah added the comment:
New changeset e95dfc5006d19e59c7871faa9973356844ddb3ae by Stefan Krah in branch
'master':
bpo-33750: Reset thread-local context precision in test_round(). (#7355)
https://github.com/python/cpython/commit/e95dfc5006d19e59c7871faa997335
Stefan Krah added the comment:
New changeset 7f1bcda9bc3c04100cb047373732db0eba00e581 by Stefan Krah (Miss
Islington (bot)) in branch '3.6':
bpo-33750: Reset thread-local context precision in test_round(). (GH-7355)
(#7356)
https://github.com/python/cpyt
Stefan Krah added the comment:
New changeset bdab3ea8b98db2133ef1e2d92b2a2c539f08ddaf by Stefan Krah (Miss
Islington (bot)) in branch '3.7':
bpo-33750: Reset thread-local context precision in test_round(). (GH-7355)
(#7357)
https://github.com/python/cpyt
Stefan Krah added the comment:
OK, thanks for checking the other tests!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
Okay that makes sense. :)
I looked a bit at the gc code. A consumer object always has one
reference to a memoryview with an export, which isn't visited. So
it looks to me that the gc_refs of that memoryview cannot fall to 0.
So memory_clear() isn't
Stefan Krah added the comment:
I would not mind backporting this. Let's think about it for a while.
--
assignee: skrah ->
resolution: fixed ->
stage: resolved -> backport needed
status: closed -> open
versions: +Python 3.6 -Python 3.7
_
Stefan Krah added the comment:
Yikes, I wasn't aware that we are that late in the 3.6 release cycle.
Perhaps it would be unusual to change it now, even though it is a bug fix.
What do others think?
--
___
Python tracker
<https://bugs.py
2101 - 2200 of 4951 matches
Mail list logo
