Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +19868
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20648
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Krah :
Synopsis: There are no relevant new features for _decimal, but it would be too
much work/error prone to have divergent code in libmpdec-2.5.0 and Python 3.9,
especially for the Linux distributions.
I'll release libmpdec-2.5.0/libmpdec++-2.5.0 in a mon
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +19872
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20652
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Krah :
Again code coverage prevents the merge button from going green:
https://travis-ci.org/github/python/cpython/jobs/695095365
"The job exceeded the maximum time limit for jobs, and has been terminated."
Why can this not run on buildbot.
Stefan Krah added the comment:
New changeset 087d612efebe7c64e5f079b07e0454111859830e by Stefan Krah in branch
'master':
bpo-40874: Update to libmpdec-2.5.0 (GH-20652)
https://github.com/python/cpython/commit/087d612efebe7c64e5f079b07e0454
Stefan Krah added the comment:
It finally went through after Travis-CI hanging for about an hour.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Change by Stefan Krah :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue40874>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
There appears to be an xlc buildbot with libmpdec failures.
libmpdec uses C99 extern inline semantics. From the brief period that I had
access to xlc I remember that xlc was quite picky about C99.
Actually all of Python uses C99. So I think xlc_r needs to be
Stefan Krah added the comment:
New changeset 83bff88b4b16fb30491faa9263bbd6f3df4bab56 by Miss Islington (bot)
in branch '3.9':
bpo-40874: Update to libmpdec-2.5.0 (GH-20652)
https://github.com/python/cpython/commit/83bff88b4b16fb30491faa9263bbd6
New submission from Stefan Krah :
>From test_decimal:
test_xor (test.test_decimal.PyIBMTestCases) ... ==17597== Invalid read of size 1
==17597==at 0x64A7E2: newline_in_string (pegen.c:940)
==17597==by 0x64A84E: bad_single_statement (pegen.c:958)
==17597==by 0x64A
New submission from Stefan Krah :
./configure --with-valgrind:
Objects/unicodeobject.c: In function ‘unicode_release_interned’:
Objects/unicodeobject.c:15672:26: error: lvalue required as left operand of
assignment
Py_REFCNT(s) += 1;
^
Objects
New submission from Stefan Krah :
Also in test_decimal, there's a small leak here:
==10040== 24 bytes in 1 blocks are definitely lost in loss record 549 of 5,095
==10040==at 0x4C2DE56: malloc (vg_replace_malloc.c:299)
==10040==by 0x643B33: fstring_compile_expr (parse_string.
New submission from Stefan Krah :
I'm opening a separate issue to prevent #40521 from getting too big.
Lists and tuples sometimes leak (starting 69ac6e58f and later):
==1445== 56 bytes in 1 blocks are definitely lost in loss record 1,542 of 4,898
==1445==at 0x4C2DE56: m
Stefan Behnel added the comment:
New changeset f7c4e236429606e1c982cacf24e10fc86ef4462f by scoder in branch
'master':
bpo-40724: Support setting buffer slots from type specs (GH-20648)
https://github.com/python/cpython/commit/f7c4e236429606e1c982cacf24e10f
Stefan Behnel added the comment:
New changeset 1e4fa91104a03c44baa241326102cbec42d387f1 by Miss Islington (bot)
in branch '3.9':
bpo-40724: Support setting buffer slots from type specs (GH-20648) (GH-20683)
https://github.com/python/cpython/commit/1e4fa91104a03c44baa241326102cb
Stefan Behnel added the comment:
New changeset 1d711f2e31e02b2e9cbe4f109bf79541f56c35a2 by Miss Islington (bot)
in branch '3.9':
bpo-40724: Fix return type of test helper function
heapctypewithbuffer_releasebuffer() (GH-20685) (GH-20690)
https://github.com/python/cpyt
Change by Stefan Behnel :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
> It's not a regression. It's just that bpo-40521 helped Valgrind to detect
> such bug :-)
Yes, I suspected that previously reachable global objects were just unreachable
after the new free lists. Th
Stefan Behnel added the comment:
New changeset 301f0d4ff9b6bd60599eea0612904f65a92e6dd9 by Shantanu in branch
'master':
bpo-33187: Document 3.9 changes to xml.etree.ElementInclude.include (GH-20438)
https://github.com/python/cpython/commit/301f0d4ff9b6bd60599eea0612904f
Stefan Behnel added the comment:
New changeset 301f0d4ff9b6bd60599eea0612904f65a92e6dd9 by Shantanu in branch
'master':
bpo-33187: Document 3.9 changes to xml.etree.ElementInclude.include (GH-20438)
https://github.com/python/cpython/commit/301f0d4ff9b6bd60599eea0612904f
Stefan Krah added the comment:
I think I'm going to revert this for 3.7 and 3.8 -- not because of xlc (it is
almost certainly a compiler or missing flag error), but because coordination
with the Linux distributions is a mess, see #40874.
I really want the system libmpdec to be the sa
Change by Stefan Krah :
--
pull_requests: +19948
pull_request: https://github.com/python/cpython/pull/20743
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Krah :
--
pull_requests: +19949
pull_request: https://github.com/python/cpython/pull/20744
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset 706de4e5a4b21880c67f6b90e3a2147a258d6fc5 by Stefan Krah in branch
'3.8':
[3.8] Revert bpo-39576: Clarify the word size for the 32-bit build. (GH-20743)
https://github.com/python/cpython/commit/706de4e5a4b21880c67f6b90e3a214
Stefan Krah added the comment:
New changeset c0b79450bc9e93105799528151c48d25af8240a3 by Stefan Krah in branch
'3.7':
[3.7] Revert bpo-39576: Clarify the word size for the 32-bit build. (GH-20744)
https://github.com/python/cpython/commit/c0b79450bc9e93105799528151c48d
Change by Stefan Krah :
--
pull_requests: +19950
pull_request: https://github.com/python/cpython/pull/20745
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Krah :
--
pull_requests: +19951
pull_request: https://github.com/python/cpython/pull/20746
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset 32c1fb07e6f2ded90e5dd24d4b46b7aa7a795d2e by Stefan Krah in branch
'3.8':
[3.8] Revert bpo-39576: docs: set context for decimal arbitrary precision
arithmetic (GH-20745)
https://github.com/python/cpyt
Stefan Krah added the comment:
New changeset 9bd891920a5186b7d02281ea9966225efa0ceba1 by Stefan Krah in branch
'3.7':
[3.7] Revert bpo-39576: docs: set context for decimal arbitrary precision
arithmetic (GH-20746)
https://github.com/python/cpyt
Change by Stefan Krah :
--
pull_requests: +19952
pull_request: https://github.com/python/cpython/pull/20747
___
Python tracker
<https://bugs.python.org/issue39
Change by Stefan Krah :
--
pull_requests: +19953
pull_request: https://github.com/python/cpython/pull/20748
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
New changeset 22faf6ad3bcc0ae478a9a3e2d8e35888d88d6ce8 by Stefan Krah in branch
'3.7':
[3.7] Revert bpo-39576: Prevent memory error for overly optimistic precisions
(GH-20748)
https://github.com/python/cpython/commit/22faf6ad3bcc0ae478a9a3e2d8e358
Stefan Krah added the comment:
New changeset 0f5a28f834bdac2da8a04597dc0fc5b71e50da9d by Stefan Krah in branch
'3.8':
[3.8] Revert bpo-39576: Prevent memory error for overly optimistic precisions
(GH-20747)
https://github.com/python/cpython/commit/0f5a28f834bdac2da8a04597dc0fc5
Stefan Krah added the comment:
The 3.9 change (see #40874) works successfully on all buildbots, except for the
32-bit xlc bot which should use c99_r.
Additionally, it has been tested with the latest gcc/clang/icc/cl.exe, static
analyzers and clang-tidy.
It survives brute force allocation
Stefan Krah added the comment:
s/icc/Python compiled with icc/
--
___
Python tracker
<https://bugs.python.org/issue40923>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
It would be easier to understand this issue if you provide the exact
command line.
icc also segfaults without -fwrapv, see #40223, so that may be the
cause here, too.
--
nosy: +skrah
___
Python tracker
<ht
Stefan Krah added the comment:
Yes, the generated Python crashes (as the link I gave shows). I'm using the
command line, so I can't be of any assistance with Parallel Studio XE.
--
___
Python tracker
<https://bugs.python.o
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue40923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
The annoying "error" looks the same as #5614, which was closed as "won't fix".
Is this the only place in the test suite now? If it is, I'm okay with
squashing the remark.
--
nosy
Stefan Krah added the comment:
I'm aware of what -fwrapv does, it is a long standing issue in Python.
I didn't try to find the exact location of overflow, since we also use -fwrapv
for gcc.
It is also possible that giving -fwrapv to icc disables another optimization
that is
Stefan Krah added the comment:
"squashing the remark" means suppressing the message from malloc().
I would really like it if the test could be executed by default though.
Looking at:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man
Stefan Krah added the comment:
Thanks for checking, it's a pity that os.putenv() does not work.
There's a global variable malloc_logger that is set from the
environment on startup:
https://opensource.apple.com/source/libmalloc/libmalloc-53.1.1/src/malloc.c
It seems to be always c
Stefan Krah added the comment:
I have two observations:
First, I think that the default DEBUG_WRITE_ALWAYS, which is the cause
of this issue, is not C standard conforming -- The standard does not
permit implementation defined diagnostics (global side effects!) on a
completely normal
Stefan Krah added the comment:
> What about overriding the default to DEBUG_WRITE_ON_CRASH if
> MallocDebugReport is not set?
That sounds like a very good compromise!
--
___
Python tracker
<https://bugs.python.org/i
Stefan Krah added the comment:
I would probably put all that code in a separate function like
init_darwin_libc(), and call init_darwin_libc() in pymain_init().
The real fun will start when we figure out which OS X versions
support this feature. I hope we have a buildbot for each
Stefan Krah added the comment:
Changing the title to get more input from others.
--
title: test_decimal.CWhitebox.test_maxcontext_exact_arith() shows "malloc:
can't allocate region" on MacOS -> OS X: malloc(): set default diagnostics to
DE
Stefan Krah added the comment:
No, it does not cause real issues. Adding this feature would just suppress
chatty diagnostics like this one, which are a bit unfriendly:
>>> [0] * 1
python3(36633,0x110c08dc0) malloc: can't allocate region
:*** ma
Stefan Krah added the comment:
But if malloc_print_configure() is not a public API, it should probably not be
used.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
And indeed, with the new decimal MAX_PREC feature, you should see
the misguided diagnostic as well on OS X:
>>> from decimal import *
>>>
>>> c = getcontext()
>>> c.prec = MAX_PREC
>>> Decimal(4).sqrt()
Decimal(
Stefan Behnel added the comment:
New changeset ec88e1bca81a167e6d5c0ac635e22f84298cb1df by Serhiy Storchaka in
branch 'master':
bpo-36543: Revert "bpo-36543: Remove the xml.etree.cElementTree module."
(GH-20117)
https://github.com/p
Stefan Behnel added the comment:
New changeset 3b97d1becbe08cf56c58d9c740a4622cbf6285fd by Miss Islington (bot)
in branch '3.9':
bpo-36543: Revert "bpo-36543: Remove the xml.etree.cElementTree module."
(GH-20117) (GH-20780)
https://github.com/p
Stefan Behnel added the comment:
The xml.etree.cElementTree module is restored. We'll see about what to do with
it later. It hurts less to keep it around than to delete it.
I think this ticket can be closed.
--
resolution: -> fixed
stage: patch review -> resolved
s
Stefan Krah added the comment:
> The first warning line in the initial message of this bug report tries to
> allocate 872 petabyte.
Yes, that's for systems like Linux where you never know what overallocation is
going to permit and subsequently freeze the system.
Special ca
Stefan Behnel added the comment:
New changeset 24b8bad6d30ae4fb37ee686a073adfa5308659f9 by scoder in branch
'master':
bpo-40703: Let PyType_FromSpec() set "type.__module__" only if it is not set
yet. (GH-20273)
https://github.com/p
Change by Stefan Behnel :
--
stage: patch review -> test needed
___
Python tracker
<https://bugs.python.org/issue40703>
___
___
Python-bugs-list mai
Stefan Behnel added the comment:
New changeset 9419158a3e67ba2eadf33215568003ed723b0a98 by Miss Islington (bot)
in branch '3.9':
bpo-40703: Let PyType_FromSpec() set "type.__module__" only if it is not set
yet. (GH-20273) (GH-20782)
https://github.com/p
Stefan Krah added the comment:
Thanks for this information. The buildbot, however, fails to compile
C99 extern inline functions. Example:
ld: 0711-317 ERROR: Undefined symbol: .mpd_issnan
I understand the C99 extern inline feature like in this explanation:
https://www.greenend.org.uk/rjk
Stefan Krah added the comment:
So it would still be interesting to see what happens if you compile
libmpdec with c99_r (emphasis mine):
"""
This command supports all ISO
C99 language features, but does
not support IBM language
extensions. Use this invocation for
*strict* con
Stefan Krah added the comment:
Can't we just use #ifndef __cplusplus instead of changing the function?
I don't think anyone compiles the affected files with a C++ compiler.
There are many areas in Include/* that fail with C++, e.g. isnan() with
-std=c++11.
--
no
Stefan Krah added the comment:
I've tested the MSVC _snprintf extremely extensively in _decimal and never had
a problem.
--
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
Thanks!
Ha, it turns out that c99_r has excellent C99 compliance. :)
> Variable arguments macro RAISE_SYNTAX_ERROR was invoked with an empty
> variable argument list.
Totally legit, we should use xlc (at least the front end) more often.
So maybe ou
Stefan Behnel added the comment:
To add to the list, Cython also calls _Py_NewReference() in its async generator
code, which uses a free-list. That code was mostly copied from the
CPython-internal implementation.
Other freelist implementations in Cython call PyObject_INIT() instead, so I
Stefan Behnel added the comment:
I looked into the freelists a bit more and (as always) it's not quite that
simple. Calling _Py_NewReference() allows keeping the "ob_type" pointer in
place, whereas PyObject_INIT() requires a blank object in order to set the type
and properly
Stefan Behnel added the comment:
It should be replaced with an actual function, which can be inline in the
non-limited case.
--
nosy: +scoder
stage: -> needs patch
type: -> compile error
versions: +Python 3.10, Python 3.9 -Python 3.6, Pyth
Stefan Behnel added the comment:
You can see it from the tags on the commit, it was fixed in Py3.8.
Duplicate of issue 33738.
--
resolution: -> duplicate
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.6, P
Stefan Behnel added the comment:
I ran into this, too. I agree that the "hackcheck" loop on heap types is
probably wrong.
https://github.com/python/cpython/blob/04fc4f2a46b2fd083639deb872c3a3037fdb47d6/Objects/typeobject.c#L5947-L5977
It was written at a time (Py2.3?) when (p
Stefan Behnel added the comment:
I was made aware [1] that the addition of the "cf_feature_version" field broke
the backwards compatibility of the "PyRun_StringFlags()" function [2]. Unlike
what the docs of "PyCompilerFlags" [3] suggest, the new field is not
Stefan Behnel added the comment:
I wasn't sure which is better – solve it or leave it. But it seems a) easy to
adapt to on user side, and b) solvable in CPython in a way that allows code
that wants to adapt to work across 3.8.x versions. Only code that does not get
adapted would risk fa
Stefan Behnel added the comment:
PRs look good to me. Here is a test that fails for me with the master branch
and works with your fixes. It has a slightly odd place in the subinterpreter
tests, but I would argue that it's not entirely misplaced there. You would want
to know
Stefan Behnel added the comment:
Feel free to use the patch in any way you like.
--
___
Python tracker
<https://bugs.python.org/issue35975>
___
___
Python-bug
Stefan Behnel added the comment:
This SO answer by Martijn Pieters explains the background:
https://stackoverflow.com/a/44854477
and links to the original python-dev discussion:
https://mail.python.org/pipermail/python-dev/2003-April/034535.html
The current implementation checks that the
Stefan Behnel added the comment:
> Giving a direct access to an array or PyObject* (PyObject**) is causing
> issues with other Python implementations, like PyPy, which don't use PyObject
> internally.
I'm wondering – if the intention is to help other implementations, then
Stefan Behnel added the comment:
> Also, later, these structures may change to be more efficient.
Tuples? Really?
Ok, quoting PEP-620:
> Members of … PyTupleObject structures have not changed since the "Initial
> revision" commit (1990)
I honestly think the reason for t
Change by Stefan Behnel :
--
keywords: +patch
pull_requests: +20258
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21092
___
Python tracker
<https://bugs.python.org/issu
Stefan Behnel added the comment:
I chose to go through the MRO, which takes multiple inheritance into account.
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Behnel :
--
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue39960>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
"""
* Doc/c-api/buffer.rst: the table with ".. c:macro:: PyBUF_INDIRECT" is wrong.
Sphinx fails because PyBUF_SIMPLE is declared twice.
=> use ":c:macro:`PyBUF_INDIRECT`" instead
"""
Hmm, grep shows:
c-ap
Stefan Krah added the comment:
Is it a bug in float.__trunc__()? It seems to me that the detailed comment
accounts for case of rounding up.
That's why < is used instead of <=.
--
nosy: +skrah, tim.peters
___
Python trac
Stefan Krah added the comment:
C99, 6.3.1.4 Real floating and integer:
"""
When a value of integer type is converted to a real floating type, if the value
being
converted can be represented exactly in the new type, it is unchanged. If the
value being
converted is in the range
Change by Stefan Krah :
--
pull_requests: +20355
pull_request: https://github.com/python/cpython/pull/21202
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
New changeset 8bea91b5e9ea07ca93958e131b436024f0b1b1cf by Stefan Krah in branch
'master':
bpo-40874 Update the required libmpdec version for the decimal module (GH-21202)
https://github.com/python/cpython/commit/8bea91b5e9ea07ca93958e131b4360
Stefan Krah added the comment:
New changeset 119de0eba839993cf6a909dba5d60202ad5566d6 by Miss Islington (bot)
in branch '3.9':
bpo-40874 Update the required libmpdec version for the decimal module
(GH-21202)
https://github.com/python/cpython/commit/119de0eba839993cf6a909dba5d602
Stefan Krah added the comment:
A very brief guide for all users of --with-system-libmpdec:
Python 3.7 and Python 3.8 both require the release with this sha256sum:
83c628b90f009470981cf084c5418329c88b19835d8af3691b930afccb7d79c7
mpdecimal-2.4.2.tar.gz
Python 3.9 requires the release
Stefan Krah added the comment:
This appears to be fixed now.
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39701>
___
___
Python-
Stefan Krah added the comment:
icc does not like the label reordering from:
ddd1949fea59f256e51191540a4446f75ed608fa
This is one step further, but not much. Possibilities are still:
1) The reordering exposes an overflow.
2) The new ordering is not supported by icc, it introduces
Stefan Krah added the comment:
cc Benjamin, in case he has any ideas: icc does not like the label
reordering in ceval.c, but that can be anything from an icc issue
to an actual overflow in ceval.c.
--
nosy: +benjamin.peterson
___
Python tracker
Stefan Krah added the comment:
Ubuntu is my main system, and it does not break the build.
If you use --with-system-libmpdec, you need to keep in sync with
the external libmpdec.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
Please name a buildbot that does not pass.
--
___
Python tracker
<https://bugs.python.org/issue40874>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Or is this CoC bait again?
--
___
Python tracker
<https://bugs.python.org/issue40874>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
If Python is packaged with **system** libmpdec, you can only use
the official Ubuntu Python/libmpdec version combination.
Which are packaged by Matthias Klose, who is on the CC list here.
Otherwise, why use the system libmpdec at all and not the version
Stefan Krah added the comment:
You are talking to the author of libmpdec *and* the _decimal module.
Perhaps this problem has occurred to me, too:
$ diff -ur mpdecimal-2.5.0/libmpdec cpython-commit/Modules/_decimal/libmpdec/
Only in mpdecimal-2.5.0/libmpdec: .objs
Only in mpdecimal-2.5.0
Stefan Krah added the comment:
This is no release blocker. Version 2.5.0 has been in 3.9 for a long time, and
people should use the correct version.
--
priority: release blocker -> normal
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
--with-system-libmpdec is a **long term** tool for distributions.
Pinning the version number ensures that they use the correct version.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
> Anthony noted a new failure related to your unreviewed and under-documented
> commit.
He claimed a failure in Ubuntu (in a manner that I took as petulant),
which isn't the case. It is a failure in a custom Ubuntu distro
that uses --with-system-lib
Stefan Krah added the comment:
> unreviewed and under-documented commit.
libmpdec has been one of the few zero fault areas of Python.
Please stop spreading FUD.
--
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
> This has nothing to do with your excellent fault rate (lack of any issues).
I sounds like that though for random people who read this issue and think
that Łukasz is the grand release manager who puts a person in his place.
That was incredibly inappropri
Stefan Krah added the comment:
> I have opened bpo-41161 to address the issue.
Thanks, that is a more considerate approach, I'll add the note!
--
___
Python tracker
<https://bugs.python.org
Stefan Krah added the comment:
Also note that people did not react at all to the fact that
coroutine storage was not thread safe across several releases.
No one asked for News entry.
But "breaking" a fringe distro seems to be a majo
Stefan Krah added the comment:
> The bot did ask you to add a news entry.
And I deliberately did not, out of politeness. Two release managers
were added and they did not ask.
> Other core developer go through great length to keep backwards compatibility
> for older or less comm
Stefan Krah added the comment:
Major correction: Victor *did* ask for a news entry, but otherwise
I would not have added one.
--
___
Python tracker
<https://bugs.python.org/issue40
1001 - 1100 of 4949 matches
Mail list logo
