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
Stefan Krah added the comment:
I see that your latest patch leaves PGO as an option, so
please ignore my previous comment.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
Agreed. I'm not sure though what the reason for this convention is:
The flow in Grammar/Grammar (low to high) feels quite natural to me.
That said, I'm +-0 on the change.
--
___
Python tracker
<http://bu
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
<http://bugs.python.org/issue24
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 prob
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
<http://bugs.python.o
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 in
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
Stefan Krah added the comment:
Are you sure that you always tested the 32-bit build, also with ICC 15.0?
--
___
Python tracker
<http://bugs.python.org/issue24
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
Stefan Krah added the comment:
We can always blame any fallout on ICC. ;)
--
___
Python tracker
<http://bugs.python.org/issue24974>
___
___
Python-bugs-list mailin
Stefan Behnel added the comment:
Patch and test look correct. They fix a bug that produces incorrect output, so
I vote for backporting them. Most code won't see the difference as whitespace
control characters are rare in attribute values. And code that uses them will
benefit from correc
Stefan Behnel added the comment:
> The only thing that was a bit mystifying were the errors during the
> initial profile run. There is so much that floats by in the terminal
> window that I completely missed the warnings about errors during the
> test run not being anything to worry
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
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
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
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."
--
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
<http://bugs.python.org/issu
Changes by Stefan Krah :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue25027>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue24
Stefan Krah added the comment:
Is Python-core built with /MD? I cannot see the flags in the buildbot
logs.
--
___
Python tracker
<http://bugs.python.org/issue25
Stefan Krah added the comment:
It seems to be /MTd. Sorry for the noise (and yay! for horizontal scrolling :).
--
___
Python tracker
<http://bugs.python.org/issue25
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 th
Stefan Krah added the comment:
Visual studio apparently has the option /F to set the stack size.
Maybe ICC has one, too.
--
___
Python tracker
<http://bugs.python.org/issue24
Stefan Krah added the comment:
Thanks, I've contacted Robert.
--
___
Python tracker
<http://bugs.python.org/issue24999>
___
___
Python-bugs-list mailing list
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 (
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 ->
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
<http://bug
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 A
Stefan Behnel added the comment:
Could I get a little note in the collections.abc section that the new ABCs
"Generator", "Coroutine" and "Awaitable" are available as backports in the
"backports_abc" package on PyPI?
https://pypi.python.org/pypi/backpo
Stefan Behnel added the comment:
Thanks, Yury!
--
___
Python tracker
<http://bugs.python.org/issue25082>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue25
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
<http://bugs.python.org/issue25
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
poss
Stefan Krah added the comment:
Argh, finally I got it: You suggested that Python users work
around this in 3.5 by setting errno from the interpreter.
I think it's better to release 3.5.1 early.
--
___
Python tracker
<http://bugs.py
Stefan Behnel added the comment:
> _collections sounds cool, but the flip side is any python without the C
> implemntation would still have the slower startup, right?
I wouldn't bother too much with that, certainly not given the order we are
talking about here. Jython's startu
Stefan Behnel added the comment:
Let's say the change minimises the dependencies. That is a reasonable goal, too.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Behnel added the comment:
Would there be a way to expose these internals rather than hiding them?
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue25
Stefan Behnel added the comment:
Understood and agreed. Second patch looks good to me.
Cython calls PyThreadState_GET() in pretty much every helper function that
deals with exceptions, but I doubt that the potential speed difference is going
to be relevant in the real world. And we target
Stefan Behnel added the comment:
LGTM
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue25047>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Stefan Krah :
--
nosy: +loewis, skrah
___
Python tracker
<http://bugs.python.org/issue25124>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 fo
Stefan Krah added the comment:
Ok, clang does not support it either:
https://llvm.org/bugs/show_bug.cgi?id=10409
--
___
Python tracker
<http://bugs.python.org/issue24
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 th
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
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 w
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
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/P
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
<http://bugs.python.org/issue25
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue25300>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<h
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.
Ther
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
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-goto
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*
optio
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
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
Stefan Krah added the comment:
Try setting the stack size to 8MB (the default on Linux) in login.conf.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue25
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 Op
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 c
Stefan Krah added the comment:
Or did you want to compute it at runtime? Actually, why not?
--
___
Python tracker
<http://bugs.python.org/issue25342>
___
___
Stefan Krah added the comment:
Adjusting the estimate at runtime sounds good to me.
--
___
Python tracker
<http://bugs.python.org/issue25342>
___
___
Python-bug
Stefan Behnel added the comment:
May I ask how difficult it is for any of the core developers to fix a known
typo in a Python source file?
--
nosy: +scoder
___
Python tracker
<http://bugs.python.org/issue25
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?
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: +
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
New submission from Stefan Seefeld:
As described in the README contained in the attached tarball, I'm observing
wrong behavior. I have based this code on my understanding of
https://docs.python.org/2/library/unittest.html#load-tests-protocol, but the
effect isn't as expected (I see
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
<http://bugs.python.org/issue25
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
<http://bugs.python.
Changes by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<http://bugs.python.org/issue25524>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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
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
reassu
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
<http://bugs.pyt
Stefan Krah added the comment:
> First garbage collector calls tp_clear for all objects in the loop
> (memory_clear() for memoryview).
If self->exports != 0 for memoryview, _memory_release() fails and the
_Py_MEMORYVIEW_RELEASED flag is not set.
I don't understand:
1) memor
Stefan Krah added the comment:
Hmm, I have some reservations about linking to statistics. They
can really give wrong incentives for committing (and IMO this
is already happening on GitHub).
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
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 wh
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
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
<http://bugs.python.org/is
Stefan Krah added the comment:
Victor, I'm adding you just in case this also affects your
optimizer (like #2).
--
___
Python tracker
<http://bugs.python.org/is
Changes by Stefan Krah :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue24623>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :).
--
no
Stefan Krah added the comment:
Thank you!
--
___
Python tracker
<http://bugs.python.org/issue25558>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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
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
Changes by Stefan Krah :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue25598>
___
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
<http://bugs.python.o
New submission from Stefan Seefeld:
I'm using the `cProfile` module to profile my code.
I tried to temporarily disable the profiler by using:
prof = sys.getprofile()
sys.setprofile(None)
...
sys.setprofile(prof)
resulting in an error.
The reason is that with `cPr
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 neede
New submission from Stefan Tatschner:
Here is a patch, which adds support for CAN_RAW_JOIN_FILTERS which is available
since linux 4.1 [1]. My patch fixes trailing whitespace issues as well. Since I
have a newer version of autotools, running "autoreconf" generates a lot of
changes,
Stefan Tatschner added the comment:
in case you don't like whitespace cleanups, here is the patch with "git diff
--ignore-space-changes".
--
Added file:
http://bugs.python.org/file41211/can_raw_join_filters-no-whitespace.diff
___
Stefan Tatschner added the comment:
Because is the first time I work with this bugtracking system on python.org,
how can I update my patch? :) Just upload a new one?
--
___
Python tracker
<http://bugs.python.org/issue25
Stefan Tatschner added the comment:
Thanks! Here is an update.
--
Added file:
http://bugs.python.org/file41218/can_raw_join_filters-no-whitespace-v2.diff
___
Python tracker
<http://bugs.python.org/issue25
Stefan Tatschner added the comment:
Hmm. I just adapted this feature request from issue22631 for the new constant
and I verified that my patch actually works. I could try to provide a test, but
then I would have to open Pandora's box as I am not a CPython developer a
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
<http://bugs.python.org/issue25
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
<h
Changes by Stefan Krah :
--
nosy: +steven.daprano
___
Python tracker
<http://bugs.python.org/issue25928>
___
___
Python-bugs-list mailing list
Unsubscribe:
4501 - 4600 of 4955 matches
Mail list logo
