Stefan Krah added the comment:
I cannot detect a speedup in test_buffer, which is a heavy user of memoryviews:
# before:
>>> a = [3.742, 3.589, 3.542, 3.495, 3.481, 3.620, 3.773, 3.755, 3.701, 3.661]
>>> sum(a) / 10
3.63589995
# after
>>> b = [3.63, 3.59
Stefan Krah added the comment:
It looks like the API would be usable, so the PR now has documentation.
--
___
Python tracker
<https://bugs.python.org/issue41
Stefan Krah added the comment:
New changeset 10e466448f67850ed7bb2e2a4e7f017f2b050cad by Srinivas Reddy
Thatiparthy (శ్రీనివాస్ రెడ్డి తాటిపర్తి) in branch 'master':
bpo-41205: Document Decimal power 0 to the 0 (GH-21386)
https://github.com/python/cpyt
Stefan Krah added the comment:
Thanks, I can confirm that the speedup for memoryview.cast() is large in
microbenchmarks.
Still, if the speedup cannot be seen in programs like test_buffer,
the amount of code that's being added for a speedup < 5% in real
world programs is quite substan
Stefan Krah added the comment:
I'm happy with the API, except that --with-system-libmpdec is naturally
broken. So I've to release a new libmpdec, which I'd rather do soon
because I don't want to revisit this later.
Antoine has looked at the API. If anyone else has re
New submission from Stefan Krah :
This issue tracks the update of the included libmpdec to version 2.5.1.
The version includes features required for #41324.
--
assignee: skrah
components: Extension Modules
messages: 374101
nosy: skrah
priority: normal
severity: normal
status: open
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +20732
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21593
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 9b9f1582753979f38d2fd927cddf0621a65e9ed6 by Stefan Krah in branch
'master':
bpo-41369 Update to libmpdec-2.5.1: new features (GH-21593)
https://github.com/python/cpython/commit/9b9f1582753979f38d2fd927cddf06
Stefan Krah added the comment:
New changeset 39042e00ab01d6521548c1b7cc6554c09f4389ff by Stefan Krah in branch
'master':
bpo-41324 Add a minimal decimal capsule API (#21519)
https://github.com/python/cpython/commit/39042e00ab01d6521548c1b7cc6554
Change by Stefan Krah :
--
components: +C API -Extension Modules
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
We need more information.
Is this 64-bit AIX?
How much physical memory does the machine have?
Linux also has over-allocation and the default for ulimit is unlimited.
But it does not attempt to over-allocate such an outrageous amount of
memory.
Neither do
Stefan Krah added the comment:
Also, perhaps build Python with -bmaxdata?
https://www.enterprisedb.com/edb-docs/d/postgresql/reference/manual/11.1/installation-platform-notes.html
--
___
Python tracker
<https://bugs.python.org/issue41
Stefan Krah added the comment:
The test (size > (size_t)PY_SSIZE_T_MAX)) has nothing to do with it. Within
Python, most sizes are ssize_t, so a value larger than SSIZE_MAX is suspicious.
AIX is an unsupported platform.
Realistically, if people want AIX to be supported, someone has to g
Stefan Krah added the comment:
> Core developers have full access to AIX system for the asking. Back to you,
> Stefan.
That sounds great. Can we contact you directly, or have I missed an earlier
announcement from someone else giving out AIX access?
Or are you working on it
Stefan Krah added the comment:
> So, this issue with v3.10 (master) appeared to me as a regression.
I understand that from your point of view it appears as a regression.
However, quoting the C standard, 7.20.3 Memory management functions:
"The pointer returned points to the start
Stefan Krah added the comment:
Thank you, David!
Now that I can test on AIX, I can confirm that the data limit is the
culprit:
libmpdec deliberately calls malloc(52631578947368422ULL) in the
maxprec tests, which is supposed to fail, but succeeds.
However, instead of freezing the machine
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +21006
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21887
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 40e700ad042089120456cc2ee79b8ca69479416b by Stefan Krah in branch
'master':
bpo-40878: xlc cannot handle C99 extern inline. (GH-21887)
https://github.com/python/cpython/commit/40e700ad042089120456cc2ee79b8c
Stefan Krah added the comment:
> -qmaxmem affects the compiler optimization.
I know, that's just from the Python README.AIX. I didn't expect it to have any
influence.
> -Wl,-bmaxdata:0x8 is a GCC command line option.
That is indeed surprising. Linking is prep
Stefan Krah added the comment:
To recap for people who find this: The problem occurs because of AIX's
extreme over-allocation and is specific to the 64-bit build.
Workarounds:
1) Something like ulimit -d 800.
2) xlc: LDFLAGS="-L/usr/lib64 -q64 -bmaxdata:0x8"
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +21009
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21890
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
New changeset 39dab24621122338d01c1219bb0acc46ba9c9956 by Stefan Krah in branch
'master':
bpo-41540: AIX: skip test that is flaky with a default ulimit. (#21890)
https://github.com/python/cpython/commit/39dab24621122338d01c1219bb0acc
Stefan Krah added the comment:
New changeset 1864eacc22485b26c0ec0a059c9330f877861afb by Miss Islington (bot)
in branch '3.9':
bpo-40878: xlc cannot handle C99 extern inline. (GH-21891)
https://github.com/python/cpython/commit/1864eacc22485b26c0ec0a059c9330
Stefan Krah added the comment:
New changeset 28bf82661ac9dfaf1b2d0fd0ac98fc0b31cd95bb by Miss Islington (bot)
in branch '3.9':
bpo-41540: AIX: skip test that is flaky with a default ulimit. (GH-21890)
(#21893)
https://github.com/python/cpython/commit/28bf82661ac9dfaf1b2d0fd0ac98fc
Change by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> compile error
___
Python tracker
<https://bugs.pyt
Change by Stefan Krah :
--
assignee: -> skrah
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Stefan Krah added the comment:
Thanks to David Edelsohn I have AIX access now. The issue reported
by Pablo is the same as #41540, for a summary see msg375480.
It is a trivial issue that requires that ulimits are in place due to
the fact that AIX over-allocates petabytes even when the physical
Stefan Krah added the comment:
Mark, do you think that we should document the other oddity as well
or should we close this?
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
I understand that both of you are in favor of #19521 (the patch of
which I have not tried yet).
Can we close this as a duplicate? Please just reopen if you disagree.
--
nosy: +skrah
resolution: -> duplicate
stage: patch review -> resolved
status
Change by Stefan Krah :
--
versions: +Python 3.10 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python
3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue19
Change by Stefan Krah :
--
nosy: +BTaskaya, Michael.Felt, kadler, skrah
___
Python tracker
<https://bugs.python.org/issue19521>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
> That's probably due to a very small size of the Paging Space of the AIX
> machine you used for testing.
That is the case, the machine has 160GB of memory and 1GB of paging space. I
guess it is configured specifically for not freezing.
> About
Stefan Krah added the comment:
Well, I misunderstood this sentence then, so it's just for testing. :)
> Our customers should use it or use ulimit -d.
One will hit this issue also when following the MAX_PREC section
in the FAQ, but that is a rare case:
https://docs.python.org/3.10
Stefan Krah added the comment:
The original patch is a bit dated, do we still need the export symbol
generation?
https://www.ibm.com/support/knowledgecenter/en/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/proguide/compiling_shared_aix.html
"Use the -G option to create a shared library fro
Change by Stefan Krah :
--
pull_requests: +21103
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21997
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
Okay, thanks. The -G option is of course attractive for Linux projects
because it requires minimal changes in the build machinery.
I've added support for libmpdec/libmpdec++ (next release) for AIX-style
shared libraries (shr.o inside libmpdec.a). Th
Stefan Krah added the comment:
I can't find the reason for:
if test -z "$EXPORTSYMS"; then
EXPORTSYMS="Modules/python.exp"
fi
Modules/python.exp is hardcoded elsewhere, and I'd rather set
EXPORTSYMS unconditionally on AIX and un
Stefan Krah added the comment:
New changeset e6dcd371b2c54a94584dd124e8c592a496d46a47 by Stefan Krah in branch
'master':
bpo-19521: Fix parallel build race condition on AIX (GH-21997)
https://github.com/python/cpython/commit/e6dcd371b2c54a94584dd124e8c592
Stefan Krah added the comment:
New changeset 88b86a9752afc2c50ca196f6ba1a8d62d71cf398 by Miss Islington (bot)
in branch '3.9':
bpo-19521: Fix parallel build race condition on AIX (GH-22001)
https://github.com/python/cpython/commit/88b86a9752afc2c50ca196f6ba1a8d
Stefan Krah added the comment:
This is in master and 3.9.1. I'll not backport to 3.8 because a release
candidate is imminent.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
vers
Stefan Krah added the comment:
If nothing has been diagnosed, I suggest closing this.
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Krah :
--
title: Decimal divisions sometimes 10x or 100x too large -> small_ints[]
modified (third party C-extension?)
___
Python tracker
<https://bugs.python.org/issu
Change by Stefan Krah :
--
nosy: David.Edelsohn, skrah
priority: normal
severity: normal
status: open
title: xlc: add -qalias=noansi -qmaxmem=-1
___
Python tracker
<https://bugs.python.org/issue41
Change by Stefan Krah :
--
keywords: +patch
pull_requests: +21183
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22096
___
Python tracker
<https://bugs.python.org/issu
New submission from Stefan Krah :
At least the xlc version on AIX 7.1 has aggressive optimizations even
with -O:
#include
#include
static int
f(long *a, long long *b)
{
int t = *a;
*b = 0; // cannot
Stefan Krah added the comment:
We would also need -fwrapv to be safe, but I cannot find an equivalent
option for xlc.
The Intel compiler had a similar failure to #40244 that was resolved
by -fwrapv (see #40223).
--
___
Python tracker
<ht
Stefan Krah added the comment:
-qmaxmem=-1 is added to disable verbose remarks.
--
___
Python tracker
<https://bugs.python.org/issue41721>
___
___
Python-bug
Stefan Krah added the comment:
New changeset 84a7917b4c9afec07575065cffa143b91fe98c14 by Stefan Krah in branch
'master':
bpo-41721: Add xlc options (GH-22096)
https://github.com/python/cpython/commit/84a7917b4c9afec07575065cffa143
Stefan Krah added the comment:
The code example is for 64-bit Linux with sizeof(long) == sizeof(long long).
It also works on 32-bit xlc with int/long.
--
___
Python tracker
<https://bugs.python.org/issue41
Stefan Krah added the comment:
New changeset fb050d0d60f38dc9b6c30df1864020a92981be5b by Miss Islington (bot)
in branch '3.9':
bpo-41721: Add xlc options (GH-22097)
https://github.com/python/cpython/commit/fb050d0d60f38dc9b6c30df1864020
Change by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
I think this is a duplicate of #41401.
--
nosy: +skrah
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Using non-ascii that require UTF-8 breaks AIX testing
___
Py
Stefan Krah added the comment:
memoryview can store anything, but only access and display
the native format. The reason is that conversions in the manner
of the struct module are very expensive.
You can construct all sorts of formats that memoryview cannot
handle:
>>> x = array(1, &
Stefan Krah added the comment:
list() has to *interpret* the endianness to display it. The endianness
of the *native* format does not matter. The endianness of an explicit
format matters, since list has to be able to convert non-native formats.
I suggest to look at XND, which is a memoryview
Stefan Krah added the comment:
It would have been nice to have had a chance to look at this, but
apparently those days are over.
--
___
Python tracker
<https://bugs.python.org/issue41
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue41732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I have been asked to backport this to 3.8. There's a very small window
of opportunity:
3.8.6: Monday, 2020-09-21
3.8.7rc1: Monday, 2020-11-02
3.8.7: Monday, 2020-11-16 (final version!)
Backporting procedures since 3.8 are unclear and a source of
con
Stefan Krah added the comment:
Thanks for the comments. Most of them should be easy to fix.
Nick Coghlan wrote:
> [...] expose the Py_buffer len field as "memoryview.size" instead of
> "memoryview.len" (to reduce confusion with "len(memoryview)" and
&
Changes by Stefan Krah :
--
dependencies: +Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
resolution: fixed -> remind
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Reopening as a reminder that it isn't fixed yet in
http://hg.python.org/features/pep-3118 .
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Revisiting memoryview.size: I foresee problems for NumPy users, since array.size
has a different meaning there:
>>> x = array([[1,2,3], [4,5,6]], dtype='q')
>>> x.shape
(2, 3)
>>> x.itemsize
8
>>> len(x)
2
>>&g
Stefan Krah added the comment:
Just as a note: It is not acceptable to be rude on the tracker or
to remove people from the nosy list as you did in #13695.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13
Stefan Krah added the comment:
py.user: The format string must always match the grammar, which is just
above the paragraph that you quoted:
[[fill]align][sign][#][0][width][,][.precision][type]
Thus, if fill and align are absent, it does not mean that you can add
arbitrary characters
Stefan Krah added the comment:
The text speaks about the regular case of a second character that
is not a valid alignment character, e.g.:
format(3.222, ".2f")
Clearly the '2' fulfills this criterion, so the parser knows that the
leading '.' is *not* a fill c
Stefan Krah added the comment:
Eric V. Smith wrote:
> As I look at it a little closer, I think I'm going to change the message to:
> "Invalid format type specified". The code has determined that instead of a
> type that's a single character long, it's rece
Stefan Krah added the comment:
Stefan Krah wrote:
>> ["xx10d"]
> look at the code now, but would the message also be raised for this spec?
>
> format(9, "xx10f")
Argh, 'd' is of course also a valid type specifier.
--
Stefan Krah added the comment:
> ... with *n*th (italic n) as alternate form
Knuth uses that in TAOCP, too. I think with or without italics it's
the most frequently used form overall.
Also the Lisp function is called nth and not n-th, even though in Lisp
it is possible to use hy
Stefan Krah added the comment:
> This is the last decision. Also, if anyone of you can, please then just >
> incorporate that final patch that Justin will make. Thanks.
Stop acting like a manager. A while ago a person had his account
disabled for constantly bumping up issues and tell
Changes by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<http://bugs.python.org/issue13816>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah :
This came up in #10419, which is already a little crowded. PyBuffer_FillInfo()
returns success if the value for 'view' is NULL.
I can't really see a reason for that. Any thoughts?
--
components: Interpreter Core
messages: 151953
nosy: n
Changes by Stefan Krah :
Added file: http://bugs.python.org/file24323/8dd9f0ea4876.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Done in: http://hg.python.org/features/pep-3118/rev/508d5e3c579c
--
dependencies: -Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
___
Python tracker
<http://bugs.python.org/issue13
Changes by Stefan Krah :
--
resolution: remind -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13411>
___
___
Python-bugs-
Stefan Krah added the comment:
I removed the dependency since PyBuffer_ToContiguous() still needs to
be fixed in abstract.c while memoryview.tobytes() now works in the
PEP-3118 repo.
--
dependencies: -Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
title
New submission from Stefan Krah :
test_pydoc fails on Ubuntu Lucid:
==
FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest)
--
Traceback (most
New submission from Stefan Krah :
test_zlib currently fails on Ubuntu Lucid:
==
FAIL: test_library_version (test.test_zlib.VersionTestCase)
--
Traceback (most
Stefan Krah added the comment:
Thanks! There was a 32-bit 1.2.5 version in /usr/local/lib and
a 64-bit 1.2.3.3 version in /lib.
gcc picks up the header from /usr/local/include, while ld is smart
enough to choose the 64-bit version. So it was a multilib issue.
While this is not the most
New submission from Stefan Krah :
Passing -UNDEBUG as CFLAGS currently doesn't work:
./configure CFLAGS="-UNDEBUG" && make
[...]
libpython3.3m.a(object.o): In function `PyObject_Str':
/home/stefan/pydev/cpython/Objects/object.c:441: undefined reference to
New submission from Stefan Krah :
In non-debug mode the read_null test fails with clang-3.0:
==
FAIL: test_disable (test.test_faulthandler.FaultHandlerTests
Stefan Krah added the comment:
STINNER Victor wrote:
> Can you try x = (int *)1; instead of x = NULL; ?
This works. - I must say that I find this new behavior of clang slightly
dangerous...
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
I've added some comments on Rietveld. This time, I pasted the email
addresses manually into the CC field, apparently without success
(I didn't receive mail).
Regarding the use of _testbuffer in the docs: I agree that it's strange,
on the other hand
Stefan Krah added the comment:
Yes, volatile works, too. That's probably the best solution.
--
___
Python tracker
<http://bugs.python.org/issue13874>
___
___
Stefan Krah added the comment:
Well, to be completely unambiguous. This works:
diff -r d2cf8a34ddf9 Modules/faulthandler.c
--- a/Modules/faulthandler.cThu Jan 26 00:15:07 2012 -0800
+++ b/Modules/faulthandler.cFri Jan 27 23:16:27 2012 +0100
@@ -943,7 +943,7 @@
static PyObject
Stefan Krah added the comment:
Jes??s Cea Avi??n wrote:
> That makes "x" and "y" volatile.
Well yes, but is that a problem?
--
___
Python tracker
<http://
Stefan Krah added the comment:
I've been busy fixing the memoryview.h issues first. Could you take a
look at:
http://hg.python.org/features/pep-3118/file/f020716704d4/Include/memoryobject.h
Changes:
a) Make all functions and the two buffer access macros part
of the limited API
Stefan Krah added the comment:
Nick Coghlan wrote:
> Radical suggestion: make it public as collections.simple_ndarray?
Heh, that's a nice one. :)
While I think that the code in _testbuffer.c is sound and very well tested,
the API is low-level and optimized for testing all sorts o
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > Nick Coghlan wrote:
> > > Radical suggestion: make it public as collections.simple_ndarray?
> >
> > Heh, that's a nice one. :)
>
> Well, the question is: does it have a point? Is this ndarr
Stefan Krah added the comment:
Antoine Pitrou wrote:
> >a) Make all functions and the two buffer access macros part
> > of the limited API again.
>
> Hmm, I don't think buffer access macros should be part of the limited
> API. If they are truely important
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > I thought the whole Py_buffer API was only temporarily removed from the
> > limited API until the issues were sorted out:
> >
> > http://bugs.python.org/issue10181#msg125462
>
> I'm talking about the
Stefan Krah added the comment:
Yes, it's really superseded by #10181 now. I'm closing as 'duplicate',
since technically it'll be fixed once the patch for #10181 is committed.
--
dependencies: -Problems with Py_buffer management in memoryobject.c (an
Stefan Krah added the comment:
STINNER Victor wrote:
> Does my commit fix the issue?
Yes, perfectly.
--
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Congratulations: You (again) have found a fundamental error in TAOCP.
Example (Third Edition, page 233):
"The following definitions seem to be appropriate for base b, excess q,
floating point numbers ..."
--
no
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue13837>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
Added file: http://bugs.python.org/file24381/a5c4a96dc981.diff
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Stefan Krah added the comment:
I've uploaded a new patch that should address the remaining issues:
o In the documentation _testbuffer has been replaced by
m.cast() + the now multi-dimensional m.tolist().
o I restored the state of the limited API. If we want
to in
Stefan Krah added the comment:
Georg Brandl wrote:
> Wow, does that mean he can cash in a Knuth check?
Two already: One for the insight that "i-th" is the only true spelling,
and now this one.
--
___
Python tracker
<http:/
Stefan Krah added the comment:
I've upgraded the Fedora buildbot to Fedora-16. The specific glibc
workaround should not be necessary any more.
So the test will now fail again on all systems that a) have the bug
and b) the tr_Tr l
Stefan Krah added the comment:
Here's a terse shell script that IMO even moderately experienced admins
will prefer to the current version.
I'm not sure if the devguide is the right place for this, since
non-devs are very welcome to set up buildbots.
--
nosy: +pitrou
Added
Changes by Stefan Krah :
Added file: http://bugs.python.org/file24399/buildslave_install.txt
___
Python tracker
<http://bugs.python.org/issue13124>
___
___
Python-bug
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file24398/buildslave_install.txt
___
Python tracker
<http://bugs.python.org/issue13124>
___
___
Python-bug
801 - 900 of 3396 matches
Mail list logo
