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 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 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 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
Stefan Krah added the comment:
> You'll have to let the readers of this thread judge that for themselves.
Ask Cowlishaw or the mpfr developers to read this thread.
As for politeness, msg372581 was entirely polite and directly answered
by an inappropriate and petulant msg372584.
Thi
Stefan Krah added the comment:
Since this is an ongoing problem: When I submitted the decNumber
patches to Cowlishaw, he asked me if I would be interested in
maintaining decNumber. I declined at the time due to time constraints.
Had I accepted, I'd control 2/3 of the decimal market now
Stefan Krah added the comment:
Yeah, I already felt a bit guilty about adding you -- it could be a compiler
bug or an actual overflow. My bet is also that the reordering exposes an
existing overflow. The reordering itself certainly looks correct to me.
When I have time, I'll try to
Stefan Krah added the comment:
New changeset 604d95e235d86465b8c17f02095edcaf18464d4c by Lawrence D'Anna in
branch 'master':
bpo-41100: fix _decimal for arm64 Mac OS (GH-21228)
https://github.com/python/cpython/commit/604d95e235d86465b8c17f02095edcaf18464d4c
Stefan Krah added the comment:
It looks like a compiler bug (line numbers are after macro expansion):
#0 0x006ea678 in _PyEval_EvalFrameDefault (f=0x886d20
<_PyRuntime+352>, throwflag=-8) at Python/ceval.c:35554
#1 0x0057167b in _PyEval_EvalCodeWithName (_co=0x
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +20395
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21243
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 1648c99932f39f1c60972bb114e6a7bd65523818 by Stefan Krah in branch
'master':
bpo-41161 Add news entry for libmpdec-2.5.0 (GH-21243)
https://github.com/python/cpython/commit/1648c99932f39f1c60972bb114e6a7
Stefan Krah added the comment:
New changeset c84d3fe6b3301c7fd4a82e63fb4d545a7b9df84b by Miss Islington (bot)
in branch '3.9':
bpo-41161 Add news entry for libmpdec-2.5.0 (GH-21243) (#21244)
https://github.com/python/cpython/commit/c84d3fe6b3301c7fd4a82e63fb4d54
Change by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
After seeing people from a certain company defend a bizarre and
broken stack with falsehoods, I apologize to Inada-san and now
assume that he had a similar experience.
--
nosy: +skrah
___
Python tracker
<ht
Stefan Krah added the comment:
Though code objects do not concern me directly, as the author of
memoryview I now concur with Inada-san that we should not support
hacks in the Python code base that benefit a single company.
--
___
Python tracker
Stefan Krah added the comment:
For clarification, the incident I referred to is entirely unrelated to *this*
issue: Of course Dino Viehland has been rational, friendly and competent.
I wanted to point out that people might have had a formative experience
*elsewhere
Stefan Krah added the comment:
It is instructive that ArchLinux quietly and professionally packaged
mpdecimal-2.5.0 hours after the release:
https://www.archlinux.org/packages/?sort=&q=mpdecimal&maintainer=&flagged=
This is in stark contrast with Python-dev, where a main
Stefan Krah added the comment:
I was the one being attacked in this issue, while releasing a zero
fault library whose release procedures resemble those found in
avionics software.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
Christian, you are also completely ignoring the original attack
of Anthony, so you are biased and there is no point continuing.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Stefan Krah :
--
components: +Extension Modules
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
I was accused of breaking the release, which is false. It is outside
of a release manager's authority to claim that an *experimental* and
*nightly* build that uses a flag in an unintended manner needs counts
as bre
Stefan Krah added the comment:
Raymond, Mark, Antoine: If you think this should be reverted, I'll
revert it.
--
nosy: +mark.dickinson, pitrou, rhettinger
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
> backwards incompatible changes.
It is not a backwards incompatible change. Slamming a 3.9 into
a nightly build has never been supported.
--
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
Since this issue has been brought to the attention of the CoC
committee. Here is how *I* report issues:
https://bugs.python.org/issue40223#msg372578
https://bugs.python.org/issue40223#msg372637
https://github.com/google/sanitizers/issues/1257
Note
Stefan Krah added the comment:
Matthias, to tell the truth, I was never sure about the soname.
I read this:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
"""
The SONAME and binary package name need not, and indeed normally should not,
change if new interface
Stefan Krah added the comment:
> In the mean time may I request that you follow our protocol for code review.
Ah, who reviews libffi? It is just updated. Not counting the thousands of
other cases people commit unreviewed, like in changing the C-API.
And no, Christian, that is
Stefan Krah added the comment:
> both 3.8 and 3.9 have to be available on the systems for the transition
> period.
If sonames can be incremented for libraries even if they are ABI compatible,
how about using up as many as you need for the Debian
package? Next time when I release mpd
Stefan Krah added the comment:
Łukasz, which one is nicer?
> reverting this patch passes all the tests, what's the motivation and why were
> there no code reviews for this?
or:
> Yeah, I already felt a bit guilty about adding you -- it could be a compiler
> bug or an act
Stefan Krah added the comment:
Finally, about the Debian issue, of course you could also link 3.8
against the static lib.
--
___
Python tracker
<https://bugs.python.org/issue40
Stefan Krah added the comment:
> Finally, while Raymond and Antoine are welcome to voice their opinions on the
> matter, your change is landing in 3.9.0b4 which I'm about to announce. So we
> won't be reverting it. In the future let's make sure we stick to the rele
Stefan Krah added the comment:
How witty!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
Christian Heimes has expressed an interest (quite rudely) in unreviewed commits
elsewhere. I wonder if that applies to everyone regardless of employer.
--
nosy: +christian.heimes, skrah
___
Python tracker
<ht
Stefan Krah added the comment:
Ah, I see that the subject has already been answered in the negative:
https://discuss.python.org/t/make-code-review-mandatory/4174
He must have forgotten.
--
___
Python tracker
<https://bugs.python.org/issue39
Stefan Krah added the comment:
Agreed, and it's even slightly worse with the ROUND_FLOOR special case:
>>> c.rounding = ROUND_FLOOR
>>> +Decimal("-0")
Decimal('-0')
>>>
That's why there are three slightly different method
Stefan Krah added the comment:
I have no opinion about this commit (I did not benchmark anything,
but I wouldn't be surprised if Victor did).
I do have the opinion that unreviewed commits occur quite frequently
and nearly every committer has made some (or a lot), including the
committer
Stefan Krah added the comment:
> In any case, I would have had a hard time giving a competent opinion on this
> issue.
Essentially it's a really simple Linux packaging issue for the
external libmpdec. To have the exact same behavior for the external
libmpdec as for the includ
Stefan Krah added the comment:
Thanks for taking a look, Antoine.
IIRC, the version pinning already accommodates Debian:
#if !defined(MPD_VERSION_HEX) || MPD_VERSION_HEX < 0x0205
#error "libmpdec version >= 2.5.0 required"
#endif
In the first libmpdec versions,
Change by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue41215>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
As noted in the first message of this thread, the sqrt-max-prec feature
(requested by Mark and Tim) was already in 3.9 long before the beta
freeze.
I'm not sure why this is not clear from the original message.
That fix is safe for Python, but not fo
Stefan Krah added the comment:
> The standalone libmpdec had to be updated, and was updated according
to the Debian-friendly way requested by Matthias himself.
Not updated, of course the sqrt-max-prec *had never been* in
the standalone libmpdec, it is new in 2.
Stefan Krah added the comment:
More than that, I had *promised* Matthias privately to release a
new libmpdec for the sqrt-max-prec feature a couple of months ago.
I request that further packaging issues will be dealt with primarily
by Matthias and myself
Stefan Krah added the comment:
A brief note for Victor that *nothing* was directed against him. On
the contrary, msg372995 was supporting him in case the commit had
actually been unreviewed, which it apparently wasn't. Sorry for
jumping on the bandwagon there.
> PEP 620 for the over
Stefan Krah added the comment:
s/PyPy as a bottleneck/the C-API as a bottle neck for PyPy/
--
___
Python tracker
<https://bugs.python.org/issue39542>
___
___
Stefan Krah added the comment:
Thank you for the report, I'll add the define or remove UNUSED in 3.9
and 3.10.
3.8 is still supposed to use libmpdec-2.4.2, though it would be
harmless to use libmpdec-2.5.0.
Are you planning to use libmpdec-2.5.0 with 3.8?
--
assignee: -&g
Stefan Krah added the comment:
New changeset 015efdbef7454a522e88cd79ba2b4cd77a5fb2a2 by Felix Yan in branch
'master':
bpo-41302: Fix build with system libmpdec (GH-21481)
https://github.com/python/cpython/commit/015efdbef7454a522e88cd79ba2b4c
Stefan Krah added the comment:
Thanks for the patch!
The integrated libmpdec-2.4.2 in Python 3.8 still has a couple of
UNUSED, so the simple approach of moving the define would not work.
It would be easy to replace the few instances of UNUSED with void
casts like in 2.5.0.
Strictly speaking
Change by Stefan Krah :
--
resolution: -> fixed
stage: patch review ->
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue41302>
___
___
Stefan Krah added the comment:
If I understand this correctly, I think this may be a duplicate of #13797.
Something like a __getbuffer__ protocol would be needed. I'm not
saying we *should* go that route, just stating the requirements
from my perspe
Stefan Krah added the comment:
Yes, let's make #13797 a superseder.
--
___
Python tracker
<https://bugs.python.org/issue41285>
___
___
Python-bugs-list m
Change by Stefan Krah :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Allow objects implemented in pure Python to export PEP 3118
buffers
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
I'm going to reclassify this as a build fix for 3.8. 3.8 promises:
#if !defined(MPD_VERSION_HEX) || MPD_VERSION_HEX < 0x02040100
#error "libmpdec version >= 2.4.1 required"
#endif
So it seems reasonable to support at least two or thr
Stefan Krah added the comment:
New changeset 16eea45fbd3b7c3d1b222b7eb7a5d7ee427f70bd by Felix Yan in branch
'3.8':
[3.8] bpo-41302: Support system libmpdec 2.5 for Python 3.8 (GH-21488)
https://github.com/python/cpython/commit/16eea45fbd3b7c3d1b222b7eb7a5d7
Stefan Krah added the comment:
Closing, thanks for all the patches!
--
stage: -> resolved
status: open -> closed
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/i
Stefan Krah added the comment:
Mark has already mentioned that setting the recursion limit to a
value higher than 2000-1 makes no sense.
Apart from that, sys.maxsize is actually documented like this:
maxsize -- the largest supported length of containers.
So it applies to Py_ssize_t
Stefan Krah added the comment:
The top level decimal.py that dispatches to either _decimal or
_pydecimal is pure Python. So perhaps these applications could
add these methods themselves:
>>> import decimal
>>> def exp(x):
... return x.exp()
...
>>> deci
Change by Stefan Krah :
--
assignee: skrah
components: Extension Modules
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a minimal decimal capsule API
versions: Python 3.10
___
Python tracker
<ht
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +20656
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21519
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Krah :
This adds a minimal decimal capsule API. As can be seen from the patch,
adding anything to decimal while doing it properly is quite labor and
testing intensive, so the intent is to *keep* the API minimal!
That said, some functions are really necessary:
1
Stefan Krah added the comment:
Closing in favor of #41324, which adds just the most important
functions.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Add a minimal decimal capsule API
___
Py
Change by Stefan Krah :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue41324>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
Also as a note for Mark and Raymond: This API is for exact conversions
and avoids the use of the context except for raising ConversionSyntax.
I'll add documentation once Antoine has tried it out for his use
Stefan Krah added the comment:
Adding Daniele Varrazzo, in case this is useful for the PostgreSQL
adapter.
--
nosy: +piro
___
Python tracker
<https://bugs.python.org/issue41
701 - 800 of 3396 matches
Mail list logo
