[issue25928] Improve performance of statistics._decimal_to_ratio and fractions.from_decimal
Changes by Stefan Krah <ste...@bytereef.org>: -- versions: -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25928] Improve performance of statistics._decimal_to_ratio and fractions.from_decimal
Stefan Krah added the comment:
On Wed, Dec 23, 2015 at 09:01:22PM +, John Walker wrote:
> Stefan, _int is a slot in Lib/_pydecimal.py. It should be defined on python
> 3.5 and tip, unsure about other versions.
>
> Python 3.5.1 (default, Dec 7 2015, 12:58:09)
> [GCC 5.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from decimal import Decimal
> >>> Decimal("100.00")
> Decimal('100.00')
> >>> Decimal("100.00")._int
> '1'
That should only happen if the C version did not build for some reason:
Python 3.6.0a0 (default:323c10701e5d, Dec 14 2015, 14:28:41)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> Decimal("100.00")._int
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'decimal.Decimal' object has no attribute '_int'
>>>
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25928>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25928] Add Decimal.as_integer_ratio()
Stefan Krah added the comment:
Let's re-target this issue:
Implementing as_integer_ratio() sounds reasonable, but let's hope
people won't try to convert Decimal('1E+99').
Mark, was there perhaps a reason not to add the method?
--
assignee: -> skrah
nosy: +mark.dickinson
title: Improve performance of statistics._decimal_to_ratio and
fractions.from_decimal -> Add Decimal.as_integer_ratio()
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25928>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] ICC compiler: ICC treats denormal floating point numbers as 0.0
Stefan Krah added the comment: The current issue description should have been fixed by #25827. Is the segfault in test_re still happening? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25934] ICC compiler: ICC treats denormal floating point numbers as 0.0
New submission from Stefan Krah: Zachary in #24999: "If that's the case, would anyone (in particular, Steve, Tim or Tim) mind if we just made the default (for MSVC as well as ICC) /fp:strict? It would be much easier to just change the global default than to try to either make it settable or to change it just when ICC is used." -- messages: 256943 nosy: haypo, mark.dickinson, paul.moore, pitrou, python-dev, r.david.murray, serhiy.storchaka, skrah, steve.dower, tim.golden, tim.peters, zach.ware priority: normal severity: normal status: open title: ICC compiler: ICC treats denormal floating point numbers as 0.0 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Changes by Stefan Krah <ste...@bytereef.org>: -- title: ICC compiler: ICC treats denormal floating point numbers as 0.0 -> Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25928] Improve performance of statistics._decimal_to_ratio and fractions.from_decimal
Stefan Krah added the comment: No, the regular build uses the libmpdec that is shipped with Python. The external libmpdec.so only comes into play if you compile --with-system-libmpdec. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: I see, thanks. I've opened #25934 to keep the issues separate. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25823] Speed-up oparg decoding on little-endian machines
Stefan Krah added the comment: Usually unaligned accesses are believed to carry a big performance penalty, though rumor has it that for the latest generation of CPUs this is no longer an issue. -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25797] Default argument values with type hints break type correctness
Stefan Krah added the comment: The compiler does not perform type checking. These are type *annotations* for third party tools like Mypy. -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Stefan Krah added the comment: > Py_ssize_t ob_array[1] Py_VARIABLE_SIZE; /* Looks weird and confusing */ Yes, I dislike that, too. The question is why gcc has supported the "struct hack" for more than 20 years but needs an annotation just for MPX. Is the annotation also needed for the C99 version (ob_array[])? Which brings me again to the topic that the MPX support needs to stabilize in gcc. ;) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25455] Some repr implementations don't check for self-referential structures
Stefan Krah added the comment: I think you may have meant Eli Bendersky -- I'm not an elementree expert (Eli, I'm adding you back just to clear this up). -- nosy: +eli.bendersky ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25598] Fix memory_hex (#9951) for non-contiguous buffers
Changes by Stefan Krah <ste...@bytereef.org>: -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25598] Fix memory_hex (#9951) for non-contiguous buffers
New submission from Stefan Krah: memory_hex from #9951 fails for non-contiguous buffers. -- assignee: skrah files: memhex.diff keywords: patch messages: 254454 nosy: skrah priority: normal severity: normal status: open title: Fix memory_hex (#9951) for non-contiguous buffers type: crash versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41002/memhex.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25465] Pickle uses O(n) memory overhead
Stefan Krah added the comment: It's a Linux issue. Disable overcommitting of memory (at your own peril) or set user limits (for example with djb's softlimit), then the process will be killed instead of freezing the machine. -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636
Stefan Krah added the comment: I had a similar issue with ucspi-ssl that was fixed by following the O'Reilly book's recommendations w.r.t WANT_READ/WANT_WRITE with non-blocking sockets to the letter. The recommendations are quite complex since apparently WANT_READ/WANT_WRITE mean different things depending on whether they occur *during a read* or *during a write*. I haven't used Python's SSL module much: Since those flags are exposed on the Python level, are users supposed to take care of the above issues themselves for non-blocking sockets? -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: > It looks to me that all issues are related to floating points. You need to compile with "-fp-model strict" or the Windows equivalent (I think "-fp-model precise"). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: If anyone worries that "-fp-model strict" will slow things down: In the Python context these settings have no measurable impact: A while ago I tested setting/restoring the control word *for every operation*, and even that did not have any impact. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25558] Use static asserts in C code
Stefan Krah added the comment: Thank you! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25558] Use static asserts in C code
Stefan Krah added the comment: Serhiy, could you please not change stuff that I maintain? I know you have the best intentions, but I really don't like these kinds of changes (just like you don't like trailing whitespace :). -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24623] Parser: broken line numbers for triple-quoted strings
Stefan Krah added the comment: Victor, I'm adding you just in case this also affects your optimizer (like #2). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24623] Parser: broken line numbers for triple-quoted strings
Changes by Stefan Krah <ste...@bytereef.org>: -- nosy: +haypo ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25525] Deallocation scheme for memoryview is unsafe
Stefan Krah added the comment: Thanks, no big problem. The thing is that the parts I wrote (Modules/_decimal/*, Objects/memoryobject.c, Modules/_testbuffer.c) have been audited rather heavily and have 100% code coverage with a privately maintained patch that inserts allocation failures. There are even tests in test_memoryview() / test_buffer() for breaking up reference cycles. So I'd really prefer not to have things labeled as potential issues when there are none. That also applies to the PyMem_NEW() "potential overflow" fix in _testbuffer.c where overflow was impossible. Thus, I'll probably revert that at some point, not out of hostility, but just because it's not my approach to software development (in the _testbuffer case, I view the 'len' parameter as a constrained type in the Ada sense where 0 <= len <= ndim = 64). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25483] Improve f-string implementation: FORMAT_VALUE opcode
Stefan Krah added the comment: The MASK idiom is nice and I think it's good to be exposed to it from time to time. -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25525] Deallocation scheme for memoryview is unsafe
Stefan Krah added the comment: First of all, the premise "exports > 0" in your example looks wrong to me. The deallocation process for the first view should start precisely when it no longer has any exports. In fact, the check for "exports > 0" is for the case when memoryview.release() is called from the Python level. Secondly, even if it did happen (show the code path leading to that!), BufferError would be set in memory_clear() and the garbage collector would throw a FatalError, i.e. step 5+ would not be reached. Lastly, I don't find it very diplomatic to use language like "Deallocation scheme for memoryview is complex and unsafe. It crashes with chained memoryviews..." when you don't seem to a test case or a clear concept of how the alleged bug should occur. -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25524] Add PyMemoryView_FromObjectWithFlags()
Changes by Stefan Krah <ste...@bytereef.org>: -- assignee: -> skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25524] Add PyMemoryView_FromObjectWithFlags()
New submission from Stefan Krah: See for example #25498. -- messages: 253787 nosy: skrah priority: normal severity: normal status: open title: Add PyMemoryView_FromObjectWithFlags() versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Stefan Krah added the comment: Florin, thanks for the explanation. I'd suggest to wait until the mpx support is stable in gcc. Some security features in gcc never take off (-ftrapv is broken, libmudflap is deprecated, ...) so it would be nice to have some reassurance. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25525] Deallocation scheme for memoryview is unsafe
Stefan Krah added the comment: The "chained memoryviews" you refer to are a hack and simply aren't supported. Please stop spreading FUD. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15994] memoryview to freed memory can cause segfault
Stefan Krah added the comment: > But I think there should be some way of guaranteeing that a memoryview will > not try to access memory which has already been freed. Unless the "buffered *self" parameter in _buffered_raw_read() is made a full PEP-3118 exporter, I'm not sure how it would be possible to prevent all examples of this kind. -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Stefan Krah added the comment: The current hack isn't necessary. I didn't review eryksun's patch in depth, but on the surface it looks good. I don't think the other issues you mentioned are closely related: The cause here is that the obj fields of both the second memoryview and the second mbuf are manually set to the address of the first memoryview, which plays havoc with the rather complex deallocation scheme. I've opened #25524 in order to make it easier to create views with detailed request flags. As a practical matter, I think we should just revert the ctypes change for 3.4 and 3.5 (after verifying a second time that PyObject_AsWriteBuffer() is exactly the same as in 3.4.0). Then we use the new function from #25524 for 3.6, which should alleviate concerns about writablility (not all extension writers read the docs:) etc. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Stefan Krah added the comment: Per the docs the readonly flag must be consistent for all consumers, so checking for writability after getting the view should be okay in principle. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Stefan Krah added the comment: If memoryview B is created from memoryview A, then B must be registered with the same ManagedBuffer as A, otherwise the whole scheme breaks down (PyMemoryView_FromObject() performs this check). PyMemoryView_FromBuffer() is really a legacy function that should be only used for creating temporary views within a function. As far as I know, it has usually been used that way from the start (since 3.0). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
Stefan Krah added the comment: We should ultimately do something like I suggested in msg235256. Everything else is a hack (N.B.: the issues that 1da9630e9b7f tried to fix were also hacks, so it isn't really the fault of that commit). -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Stefan Krah added the comment: > The Python MPX binary will be built with –O0 because other optimization > levels will change instruction order and cause crashes, making it useful for > debugging purposes. I've trouble understanding this: Is the gcc mpx feature not stable? Looking at the patch, we'd introduce many new macros for everyone to learn, but I'm generally not too enthusiastic about the proliferation of memory protection schemes after having been bitten by a bug in FORTIFY_SOURCE memmove wrappers. :( -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25342] test_json segfault on OpenBSD
Stefan Krah added the comment: Adjusting the estimate at runtime sounds good to me. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25342] test_json segfault on OpenBSD
Stefan Krah added the comment: Try setting the stack size to 8MB (the default on Linux) in login.conf. -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25342] test_json segfault on OpenBSD
Stefan Krah added the comment: It's not noise, we also have problems on Windows with test_json. In theory we should set Py_DEFAULT_RECURSION_LIMIT in Python/ceval.c to appropriate values for the default OS stack sizes in order to get a proper RuntimeError instead of a segfault. For OpenBSD it's clearly too high for the default. Could you try to find a safe value (perhaps 500 instead of 1000) for OpenBSD's default? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25342] test_json segfault on OpenBSD
Stefan Krah added the comment: Or did you want to compute it at runtime? Actually, why not? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25342] test_json segfault on OpenBSD
Stefan Krah added the comment: The ratio (1000/8MB) seems to be stable on Linux. Perhaps we could write a getrlimit program for ./configure to get the stack size and adjust the recursion limit to keep the ratio the same. It's just an estimate of course. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Stefan Krah added the comment: > Third party modules might need patching to work with MPX... If the flags go into CFLAGS, these modules won't compile with distutils. Perhaps we should also add LDFLAGS_NODIST, if that would solve your problem. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25311] Add f-string support to tokenize.py
New submission from Stefan Krah: I think tokenize.py needs to be updated to support f-strings. BTW, the f-string implementation seems to be incredibly robust. Nice work! -- components: Library (Lib) messages: 252274 nosy: eric.smith, skrah priority: normal severity: normal stage: needs patch status: open title: Add f-string support to tokenize.py type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Stefan Krah added the comment: Wouldn't setting CFLAGS be sufficient? ./configure CFLAGS="-fcheck-pointer-bounds -mmpx" Otherwise we could also add --with-stack-protector and --with-fortify-source and others. I'm not sure if we should add a special --with* option for every gcc flag. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Stefan Krah added the comment: > Whether the hardware is MPX enabled is irrelevant for the build process. The build process is only one part of the equation. Compilers do have bugs (Python has been affected by gcc, Visual Studio and suncc bugs), and we should test the actual generated MPX code. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] Intermittent segfaults on PPC64 AIX 3.x
Stefan Krah added the comment: > It's possible that Python needs to be built with special options to allow > additional malloc space (-bmaxdata:0xN000). It seems to be the case, see Misc/README.AIX. This could explain the MemoryErrors, but not the segfaults. Are computed-gotos stable on gcc-AIX? The README recommends disabling them for xlc. I'm also not sure how well Python supports threads on AIX. Often these problems go away on unsupported platforms when configuring --without-threads. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25302] Memory Leaks with Address Sanitizer
Stefan Krah added the comment: Static types leak memory on finalization, see PEP 3121. Normally it does not matter, but you see it when embedding Python. PEP 3121 isn't widely implemented because a) it complicates the code for large modules and b) there are some performance issues. There are several other open issues for the problem, so I'm closing this one. -- nosy: +skrah resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] Intermittent segfaults on PPC64 AIX 3.x
Stefan Krah added the comment: If you have time, you could use an explicit seed (and gdb): # test_email segfault: ./python -m test -j 1 -u all -W --randseed 5634141 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] Intermittent segfaults on PPC64 AIX 3.x
Stefan Krah added the comment: And the segfaults are apparently somewhat random. This is beginning to look like an issue unrelated to decimal that was perhaps recently introduced (in which case "hg bisect" would be the fastest way to debug). http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4183/steps/test/logs/stdio [129/399/3] test_email Fatal Python error: Segmentation fault Current thread 0x0001 (most recent call first): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/email/utils.py", line 57 in _has_surrogates File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/email/message.py", line 264 in get_payload File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_email/test_email.py", line 3463 in test_long_lines File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 600 in run File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 648 in __call__ File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__ File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__ File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__ File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__ File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__ File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/runner.py", line 176 in run File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1775 in _run_suite File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1809 in run_unittest File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 159 in test_runner File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 113 in runtest File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 289 in run_tests_sequential File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 331 in run_tests File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 362 in main File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 404 in main File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 426 in main_in_temp_cwd File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/__main__.py", line 3 in File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 85 in _run_code File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 170 in _run_module_as_main -- title: test_decimal sometimes crash on PPC64 AIX 3.x -> Intermittent segfaults on PPC64 AIX 3.x ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
Stefan Krah added the comment: I've checked: test_decimal does not require abnormal amounts of memory or stack. On Linux/x86 a stack size of 256 (default 8192) is sufficient, and memory requirements aren't that high. We assumed that there is some memory limit on the buildbot, since in a later run test #pwmx330 failed with MemoryError. The easiest way to debug this is to rerun the whole test suite under gdb with the same random seed as in http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4173/steps/test/logs/stdio -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Changes by Stefan Krah <ste...@bytereef.org>: -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25300] Enable Intel MPX (Memory protection Extensions) feature
Stefan Krah added the comment: In principle adding the option is fine, but do we have a buildbot with a Skylake processor? We have lots of options that are untested and that break periodically. -- nosy: +zach.ware ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
Stefan Krah added the comment: Usually these segfaults are toolchain bugs (I've had at least 8, including gcc, suncc, libc...). Just a couple of observations: - The bot builds with -DCONFIG_32=1 -DANSI=1 despite being PPC64. - When we had an AIX snakebite machine, the xlc compile worked on AIX (using about 50 obscure command line arguments). - In the default build, libmpdec functions use a lot of stack memory (for optimization while avoiding alloca). But there are no recursive tests, so a stack overflow would seem unlikely. -- nosy: +David.Edelsohn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23640] int.from_bytes() is broken for subclasses
Stefan Krah added the comment: > There are similar issues with Decimal.from_float() (C implementation only), > chain.from_iterable(), epoll.fromfd() and kqueue.fromfd(). All these > alternative constructors don't call __new__ or __init__. Could you create new issues? I need a summary. :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24520] Stop using deprecated floating-point environment functions on FreeBSD
Stefan Krah added the comment: Regarding volatile: gcc/clang seem to honor *some* changes to the control word. At least in libmpdec both compilers have always left the settings 80bit-prec/ROUND_CHOP intact, even though it's not the default. Let's rewrite Python in asm to avoid these issues. :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25124] No single .msi available for 3.5 release
Changes by Stefan Krah <ste...@bytereef.org>: -- nosy: +loewis, skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24520] Stop using deprecated floating-point environment functions on FreeBSD
Stefan Krah added the comment: In theory we should set FENV_ACCESS whenever the control word is changed (C99): "If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma "off", the behavior is undefined." In practice gcc ignores the pragma, icc and cl.exe use it, not sure about clang. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24520] Stop using deprecated floating-point environment functions on FreeBSD
Stefan Krah added the comment: Ok, clang does not support it either: https://llvm.org/bugs/show_bug.cgi?id=10409 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4
Stefan Krah added the comment: Yes, errno should always be cleared before use (in C99 at least, not sure what the crt does). -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4
Stefan Krah added the comment: Clearing is easy: errno = 0; :) C library functions are not supposed to set errno to 0 by themselves (C99: paragraph 7.5). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4
Stefan Krah added the comment: Steve, sorry if I misunderstand you: My point (and eryksun's) was that errno is currently not cleared before the call to format_time() in Modules/timemodule.c:657 I didn't look at this issue in depth, just pointing out a possible cause. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25087] Type variable substitution in type instances
New submission from Stefan Krah:
If a type scheme is instantiated, should the type variables in the
class body be substituted? This is an example (typed by hand on
a locked down Windows machine, may contain errors):
alpha = TypeVar('alpha')
beta = TypeVar('beta')
class ABTuple(Generic[alpha, beta]):
def __init__(self, a : alpha, b : beta):
self.value = (a, b)
get_type_hints(ABTuple.__init__)
==> {'b': ~beta, 'a': ~alpha}
IntIntTuple = ABTuple[int, int]
IntIntTuple
==> __main__.ABTuple[int, int]
get_type_hints(IntIntTuple.__init__)
{'b': ~beta, 'a': ~alpha}
^^ ^^
Since the type has been specialized, these should ideally be 'int'.
--
components: Interpreter Core
messages: 250565
nosy: gvanrossum, skrah
priority: normal
severity: normal
status: open
title: Type variable substitution in type instances
type: behavior
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25087>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5
Stefan Krah added the comment: I think the issue can be closed (after updating "what's new"). Even if we wanted to keep backwards compatibility, it's too late now. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25079] Tokenize generates NL instead of NEWLINE for comments
Stefan Krah added the comment: See: https://docs.python.org/3/reference/lexical_analysis.html#blank-lines -- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python, skrah resolution: -> not a bug stage: -> resolved status: open -> closed type: behavior -> ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25079> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5
Stefan Krah added the comment: According to the human readable grammar in the docs https://docs.python.org/3/reference/expressions.html#calls I'd say this was a bug that is now fixed in 3.5. The call should either take a single unparenthesized generator expression or an argument_list (which may contain parenthesized generator expressions). -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: Thanks, I've contacted Robert. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
Changes by Stefan Krah <ste...@bytereef.org>: -- nosy: +larry ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: Yes, according to C99 the shift is undefined: 6.5.7: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
Stefan Krah added the comment: If the scientific stack is unusable, I think this should be a release blocker. -- nosy: +skrah priority: normal -> release blocker ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: Perhaps the stack overflow hypothesis applies here, too. You could try changing Py_DEFAULT_RECURSION_LIMIT in ceval.c to lower values. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
Stefan Krah added the comment: Is Python-core built with /MD? I cannot see the flags in the buildbot logs. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
Stefan Krah added the comment: It seems to be /MTd. Sorry for the noise (and yay! for horizontal scrolling :). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules
Stefan Krah added the comment: The reason I asked: We had issues where extension modules linked against a different CRT had isolated locale settings from the interpreter, i.e., changes made by the module would not be seen by the interpreter. I don't know if this is still an issue with the new runtimes. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: Visual studio apparently has the option /F to set the stack size. Maybe ICC has one, too. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC
Stefan Krah added the comment: The buildbot segfaults all over the place, also in test_tokenize and test_json: http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/89/steps/test/logs/stdio Running the tests under the VS debugger is probably the fastest way to find out why (I don't have the Intel compiler). -- nosy: +skrah ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24915] Profile Guided Optimization improvements (better training, llvm support, etc)
Stefan Krah added the comment: Just (hopefully) for extra clarity: As you mentioned, the 3.6 patch is perfect for 3.5, too. The reason why 3.5 was brought up is to ask Larry, our release manager, to allow it already for 3.5. Technically it's an enhancement/new feature, but practically it is zero risk and for PR reassons we should probably not "make 2.7 faster" before 3.5. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24915] Profile Guided Optimization improvements (better training, llvm support, etc)
Stefan Krah added the comment: I don't think we should provide any performance guarantees in the Makefile. +1 for not special-casing x86 (does it include amd64?). As I understood, Antoine was not talking about a unified patch but about applying the 3.6 patch to 3.5 right away. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model
Stefan Krah added the comment: Hmm, I don't see a 32-bit ICC buildbot. This problem can only occur on 32-bit with -DPPRO defined. Please go ahead and commit the patch. The inline asm miscompilation problem I mentioned earlier was solved in 12.0 (I think), so let's just assume it's gone (probably it has never been an issue for MASM anyway). -- assignee: -> zach.ware ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model
Stefan Krah added the comment: We can always blame any fallout on ICC. ;) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model
Stefan Krah added the comment: Are you sure that you always tested the 32-bit build, also with ICC 15.0? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model
Stefan Krah added the comment: Also note that ICC <= 11.0 did not handle __GNUC__ inline asm correctly, see the comment: Modules/_decimal/libmpdec/umodarith.h:391 I've disabled asm for Linux/ICC in setup.py. I don't know how the situation is with MASM inline asm, but I'd recommend to test at least a couple of exact multiplications and divisions with operands of about 10 digits (the asm is only used for bignums). There is already one bignum test in test_decimal that *should* catch any oddities, but testing a bit more can't hurt. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model
Stefan Krah added the comment: Steve: What do you mean by "global option"? The C99 standard says that FENV_ACCESS (if set), is active until the end of the translation unit (here: mpdecimal.c). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model
Stefan Krah added the comment: On Linux ICC has something like "fast-math" by default. The situation is a bit annoying: On Unix ICC defines __GNUC__, but does not really have all the features. Here ICC defines _MSC_VER, but does not behave like cl.exe. [I know it's a hard problem to be fully compatible, so I'm not blaming the authors.] What happens if you take the C99 path (starting in mpdecimal.c:48)? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model
Stefan Krah added the comment: If "#pragma float_control(precise, push)" is exactly the MSVC default then I'm fine with putting it on top of FENV_ACCESS. There's nothing speed sensitive going on here: In the 32-bit build the x87 FPU is used for modular multiplication of integers and needs the control word set to 80-bit prec + ROUND_CHOP. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24913] newblock() Uninitialized Variable
Stefan Krah added the comment: I guess that in the test case the stop parameter is set to 4 in deque_index(), but it should be clamped to 3. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24913 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24915] Profile Guided Optimization active by-default
Stefan Krah added the comment: My initial reaction is that the default should be optimized for short build times. I would not want to type disable-profile-opt every time I'm running the tests. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24921] Operator precedence table in 5.15 should be highest to lowest precedence
Stefan Krah added the comment: Yacc uses low to high. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24921 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24831] Load average in test suite too high
Stefan Krah added the comment: Actually, for ecryptfs we could just check for ~/.ecryptfs and then use /tmp. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24831 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24831] Load average in test suite too high
Stefan Krah added the comment: Yes, the current scheme is probably good for easy buildbot cleanup. Maybe we can blacklist some filesystems to choose the temporary directory. If that's easily possible, it would be a good solution at least for ecryptfs. I've removed ecryptfs from my setup, since speedwise it's not production-ready for encrypting an entire home directory. The Ubuntu setup is a bit of a trap, since the encryption is completely transparent to the user (i.e. mounting ecryptfs occurs automatically on login). So if you install Ubuntu as the first system on new hardware and choose the ecryptfs option, after a while you forget about ecryptfs entirely and blame any slowness on the hardware or the software. -- priority: high - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24831 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24831] Load average in test suite too high
Stefan Krah added the comment:
It's very likely an I/O issue. There are several large file
tests that run even if 'largefile' is disabled. It already
helps a lot if the following tests are decorated with
requires_resource('largefile'):
test_mmap: class LargeMmapTests()
test_io: large_file_ops()
test_largefile: all tests
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24831
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11677] make test has horrendous performance on an ecryptfs
Stefan Krah added the comment: I don't know whether this is worth reopening, but the ecryptfs performance is still very poor on my Lenovo T400 (see #24831). For most people an extra option for choosing the tmpdir would not help, since they'd simply blame the hardware or the test suite. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11677 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24831] Load average in test suite too high
Stefan Krah added the comment: Thanks, this clears up the mystery! -- I made the mistake of choosing the eCryptfs-homedir option when installing Ubuntu, so now I have eCryptfs on top of LVM on top of full-disk encryption. So I can't create sparse files in my home directory, but I *can* create sparse files with zero overhead in /tmp. The test suite runs smoothly from /usr/local. Should we perhaps create temp files in /tmp rather than in a subdir of the build directory? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24831 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15944] memoryviews and ctypes
Stefan Krah added the comment: Done. Thanks for the patch. -- components: +Interpreter Core resolution: - fixed stage: patch review - resolved status: open - closed versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23756] Tighten definition of bytes-like objects
Stefan Krah added the comment: I would commit this, except that I'm not too happy with the use of the term bytes-like in general. Yesterday I mistyped this: import ctypes x = ctypes.c_double m = memoryview(x) Traceback (most recent call last): File stdin, line 1, in module TypeError: memoryview: a bytes-like object is required, not '_ctypes.PyCSimpleType' The previous error message was (changed in #16518) was: _ctypes.PyCSimpleType does not support the buffer interface. Which I find much clearer. Memoryviews (for better or worse, but PEP-3118 was accepted) are Mini-NumPy-arrays. I'm still not sure if we should hide that from users. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23756] Tighten definition of bytes-like objects
Stefan Krah added the comment: For end users it's probably adequate. But several committers find the term confusing (msg236283, msg188484). :) Anyway, I'm going to commit this since it adds clarity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23756] Tighten definition of bytes-like objects
Stefan Krah added the comment: Martin, thanks for the patch! -- resolution: - fixed stage: patch review - resolved status: open - closed versions: +Python 3.6 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23756 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24831] Load average in test suite too high
New submission from Stefan Krah: On my machine (Lenovo T400, Linux) the load average during running the 2.7 test suite is about 0.5 (with some exceptions like test_io). The system is still usable even during test_io. In 3.6 the load average is 2.0, with some tests making the system practically unusable (e.g. test_mmap). -- components: Tests messages: 248275 nosy: skrah priority: high severity: normal stage: needs patch status: open title: Load average in test suite too high type: resource usage versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24831 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24831] Load average in test suite too high
Stefan Krah added the comment: Scratch the comment about test_io in 2.7: It also renders the system unusable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24831 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15944] memoryview: allow all casts to bytes
Changes by Stefan Krah ste...@bytereef.org: -- title: memoryviews and ctypes - memoryview: allow all casts to bytes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15944] memoryviews and ctypes
Stefan Krah added the comment: Ok, shall we sneak this past Larry for 3.5? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15944] memoryviews and ctypes
Stefan Krah added the comment: If people are content with writing m[124:128] = b'abcd' and accept that tolist() etc. won't represent the original structure of the object, then let's do it. On the bright side, it is less work. -- I'll review the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15944 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
