Stefan Krah added the comment:
New changeset 938045f335b52ddb47076e9fbe4229a33b4bd9be by Stefan Krah (Bo
Bayles) in branch 'master':
bpo-34179: Make sure decimal context doesn't affect other tests. (#8376)
https://github.com/python/cpython/commit/938045f335b52ddb47076e9fb
Stefan Krah added the comment:
New changeset 92ce6a64afcebd414def3b80b18b56448792a587 by Stefan Krah (Miss
Islington (bot)) in branch '3.7':
bpo-34179: Make sure decimal context doesn't affect other tests. (GH-8376)
(#8383)
https://github.com/python
Stefan Krah added the comment:
New changeset 9c136700aa1f755fa2ea64594688a0930b716597 by Stefan Krah (Miss
Islington (bot)) in branch '3.6':
bpo-34179: Make sure decimal context doesn't affect other tests. (GH-8376)
(#8384)
https://github.com/python
Stefan Krah added the comment:
Ok, looks fixed to me.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue33731>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
PyBUF_RECORDS pulls in PyBUF_STRIDES, which should IMO not be done in a stable
release.
Maybe (PyBUF_CONTIG_RO|PyBUF_FORMAT), but I'm uneasy even about that. The
potential for breakage is huge.
--
___
P
Stefan Krah added the comment:
The thing is that Python explicitly supports any object as the "message".
I was quite pleased when I discovered that because it provides a way
to include both signals and the condition list in the "message", which can be
used in programs fo
Stefan Krah added the comment:
pypy3 actually took over the terse exceptions, but without the conditions.
They'd also need error codes from libmpdec now.
>>>> huge = Decimal('9' * 99)
>>>> huge.quantize(Decimal('0.1'))
Traceback (most recent
Stefan Krah added the comment:
I'm using "master" in memoryview because of the audio connotation ("the
source from which all copies will be produced"):
https://en.wikipedia.org/wiki/Audio_mastering
The ManagedBufferObject is literally the source from whic
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue34605>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I commented here to explain the master <-> view terminology of memoryview.
If anyone wants to change that, please open a separate issue and add me as
the author to the nosy list.
--
___
Python tracker
Stefan Krah added the comment:
Trying to remove myself from the nosy list again (I know that the interface
sometimes surprisingly adds/removes persons).
--
___
Python tracker
<https://bugs.python.org/issue34
Change by Stefan Krah :
--
nosy: -skrah
___
Python tracker
<https://bugs.python.org/issue34605>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue34778>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
>>> mview.format
'B'
>>> mview[:] = array.array('B', b'hello')
Bytes have format 'B', so this works as expected.
--
assignee: -> skrah
nosy: +skrah
resolut
Stefan Krah added the comment:
I just want to add one more voice for allowing the status quo:
C, OCaml, SML, Haskell allow the assignment, Ruby disallows it.
The ML family must allow it, since "let (x) = 10" is pattern matching
under the hood, and (10) = 10.
In C (gcc, clang a
Stefan Krah added the comment:
> We do not want to change it to 64-bit because it’s not supported in all
> environments.
Does this also apply to changing the precision temporarily? Because
that is what happens for other platforms, see Include/pyport.h:
HAVE_PY_SET_53BIT_PRE
Stefan Krah added the comment:
I forgot to comment on this:
> fixing this in general would allow keeping the FPUCW on i387 unchanged too.
Actually dtoa.c (which is used on i387) explicitly requires to change
the control word.
Looking at the test results, it seems to me that a couple of te
Stefan Krah added the comment:
Here's a baroque patch for _decimal. It's complicated by the fact
that there's no way of knowing what kind of UTF-8 fragments might
be hidden in multi-byte separators or decimal points.
--
Added file: http://bugs.python.org/file30407/
Changes by Stefan Krah :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17768>
___
___
Python-bugs-list
Stefan Krah added the comment:
With this patch float and int should behave like Decimal. It may
break existing code that (accidentally) uses both legacy zero padding
and explicit alignment.
--
keywords: +patch
stage: needs patch -> patch review
versions: -Python 3.3
Added file: h
Stefan Krah added the comment:
Hi, I think this broke the tiger buildbot:
http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6368/steps/test/logs/stdio
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
+1 for removing all occurrences of "register".
Regarding the grammar, we have:
function-definition:
declaration-specifiers-opt declarator declaration-list-opt
compound-statement
So I think that "part of an external declaration" ref
Stefan Krah added the comment:
I'd use foldl() in functional languages, where the default is part
of foldl() and not of max().
Translated to Python, I'm thinking of:
it = iter([328, 28, 2989, 22])
functools.reduce(max, it, next(it, None))
2989
I agree with Raymond that a default
Stefan Krah added the comment:
The docs say:
"Native size and alignment are determined using the C compiler’s sizeof
expression. This is always combined with native byte order."
sizeof(long) is 8 on your platform, so I don't see anything wrong here.
Or is another part of th
Stefan Krah added the comment:
Building the external packages isn't fixed yet, but I don't know if it's
worth the trouble.
--
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
Basically someone has to review the patch and commit it. I'm not really
using ctypes, so for me a decent review would take a while.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
With gcc I cannot reproduce this either. For icc perhaps we should
just set "-fp-model strict" in ./configure.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
I uderstand that you are building Python using "emerge". I would try to get a
release from python.org, do a normal build ...
make distclean
./configure --prefix=/tmp --with-pydebug --with-valgrind
make
make install
...
then install matplotlib using
Stefan Krah added the comment:
I would probably work on it (it's basically implemented in _testbuffer.c),
but I'm not sure if the NumPy community will actually use the feature.
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
The request is certainly valid, but the patch is tricky to review.
--
___
Python tracker
<http://bugs.python.org/issue17
Stefan Krah added the comment:
A similar issue was closed, see msg157249. The error looks deliberate
to me, so let's close this, too.
--
nosy: +skrah
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://b
Stefan Krah added the comment:
Martin, msg196534 shows that you are building with -DPy_LIMITED_API=1.
You can either use the limited API or --with-pydebug, but not both.
[As I said in the other issue, IMHO it is better to use a minimal set
of build options when reporting bugs
Stefan Krah added the comment:
I think I understand now: If you used the strategy from msg196520,
of course you get the Gentoo flags.
What you really should do is download a release or get a checkout
from hg.python.org and build that _without_ using "e
Stefan Krah added the comment:
Well, these look like Gentoo build flags. Did you or "emerge" or
anything else export CFLAGS in the shell?
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
Wikipedia sounds good. Let's avoid linking directly to "free" versions. :)
--
___
Python tracker
<http://bugs.pyt
Stefan Krah added the comment:
BTW, in _decimal the feature can already be enabled with:
./configure CFLAGS=-DEXTRA_FUNCTIONALITY
>>> IEEEContext(DECIMAL128)
Context(prec=34, rounding=ROUND_HALF_EVEN, Emin=-6143, Emax=6144, capitals=1,
clamp=1, flags=[], traps=[])
>>> IEE
Stefan Krah added the comment:
Is the distutils freeze still in place? If not, I'll commit initfunc2.patch.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue18606>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Hmm, I've managed to produce the error with 3.1:
$ python3.1
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
File "/usr/lib/python3.1/io.py", line 60, in
import _io
File
Stefan Krah added the comment:
The funny thing is, in 3.3 I can't reproduce it (i.e. I only get
the KeyboardInterrupt). So I'm not sure if this happens more often
now.
^CTraceback (most recent call last):
File "", line 989, in _find_and_load
File "", l
Stefan Krah added the comment:
The patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue14630>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
I'm not sure what to do. Martin's opinion was that the change should
be reverted:
http://mail.python.org/pipermail/python-dev/2012-March/117390.html
--
___
Python tracker
<http://bugs.python.o
New submission from Stefan Krah :
The build --without-threads segfaults in run_tests.py:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/2123/steps/test/logs/stdio
--
components: Tests
messages: 159496
nosy: skrah
priority: release
Stefan Krah added the comment:
This issue is now apparently causing a segfault:
(gdb) r ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600
Starting program: /home/stefan/pydev/cpython/python
./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600
[...]
Program received signal
Stefan Krah added the comment:
Appears to be related to #14583.
--
keywords: +buildbot
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> try/except import fails --without-threads
__
New submission from Stefan Krah :
Seen on the Gentoo buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/2154/steps/test/logs/stdio==
ERROR: test_format (test.test_bool.BoolTest
Changes by Stefan Krah :
--
type: crash -> behavior
___
Python tracker
<http://bugs.python.org/issue14686>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
On another bot:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/2205/steps/test/logs/stdio
[250/364] test_bool
python: Objects/unicodeobject.c:13501: formatlong: Assertion
`unicode_modifiable(result)' failed.
Fatal Python
Stefan Krah added the comment:
I think the issue is fixed in all affected branches. Georg, can we close it?
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.or
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue9530>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Stefan Krah added the comment:
Vinay's patch solves the problem. +1 for committing.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
I tested the patch, it works fine. I can't test the popup situation
since I currently only have ssh access.
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
The proposal makes sense at first glance, but I agree with Mark that it is
not clear what should be done. For example, all arrays in Python silently
convert to inf:
>>> from numpy import array
>>> x = array([1,2,3], 'f')
>>> x
Stefan Krah added the comment:
I agree. Fixing all this would probably require a PEP. It looks like the
original plan was to provide a facility to turn off the Overflow exception:
http://mail.python.org/pipermail/python-dev/2000-May/003990.html
Stefan Krah added the comment:
This looks quite impressive, so sorry for immediately jumping in with
criticism. -- I've benchmarked the things I worked on, and I can't see
any speedups but some significant slowdowns. This is on 64-bit Linux
with a Core 2 Duo, both versions compiled
Stefan Krah added the comment:
> > Modules/_decimal/tests/bench.py:
> >
> >
> > Not much change for floats and decimal.py, 8-10% slowdown for _decimal!
>
> This result is not unexpected, as I have no inline cached versions of
>
Stefan Krah added the comment:
The sysconfig docs say: "configuration variables relevant for the
current platform"
If get_config_var('SIZEOF_VOID_P') is meaningless for universal builds,
then IMO it should return None. None would then mean either "
Stefan Krah added the comment:
The tests for arrays with suboffsets literally need sizeof(void *).
I don't think C guarantees SIZEOF_VOID_P == SIZEOF_SIZE_T. If HAVE_SSIZE_T
is defined in pyport.h, AFAICS no such check is made.
Of course these concerns may be entirely theore
Stefan Krah added the comment:
Apparently the AS/400 had 128 bit pointers and IBM's "System i" still has them:
http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/651
http://www-01.ibm.com/support/docview.wss?uid=swg27019425
So I'll leave the SIZEO
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue14813>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I also would appreciate if the VS 2008 build still worked. Currently I
can't build the 64-bit version with either VS 2008 or VS 2010:
TRACKER : error TRK0002: Failed to execute command: ""C:\Program Files
(x86)\Microsoft Visual Studio 10
.0\VC\B
Stefan Krah added the comment:
This happens every time. It wasn't an issue with VS 2008. I'm building
on the command line:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\vcvars64.bat"
msbuild /p:useenv=true pcbuild.sln /p:Configuration=Debug /p:Platf
orm
Stefan Krah added the comment:
This is bizarre. The same command line that fails during build works
when I paste it manually:
[During build]
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64\CL.exe /c
/I..\Include /I..\PC /Zi /
nologo /W3 /WX- /Od /Ob1 /Oi /Oy- /D _CONSOLE
Stefan Krah added the comment:
Martin v. L??wis wrote:
> I'm having problems with F-Secure, VS 2010, and make_buildinfo. F-Secure
> thinks that make_buildinfo.exe has a virus in it, and quarantines it.
I don't have a virus scanner, since I only use the VM for testing.
Appare
Stefan Krah added the comment:
Here's a patch. I can build win32 and "Release|x64". However, the
executables immediately exit; this might be related to #14822.
--
keywords: +patch
Added file: http://bugs.python.org/file25608/vs-9.0.diff
___
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue14822>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Regarding the VS 2010 build failure, using the cross tools builds
python_d.exe:
"C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
msbuild /p:useenv=true pcbuild.sln /p:Configuration=Debug /p:Platform=x64
Stefan Krah added the comment:
Probably line endings. It applies with cygwin's patch:
C:\Users\stefan\pydev\cpython>patch -p1 < vs-9.0.diff
patching file PC/VS9.0/
Stefan Krah added the comment:
Hm, vs-9.0.diff applies here on Linux, too. A final try... :)
--
Added file: http://bugs.python.org/file25610/vs-9.0-linux.diff
___
Python tracker
<http://bugs.python.org/issue14
Stefan Krah added the comment:
[VS 2008]
Most recent tip is ok here, too: all executables run again.
There's still a link failure in "Debug|x64" mode, but that appears
harmless:
lib /def:python33stub.def
/out:C:\Users\stefan\pydev\cpython\PC\VS9.0\x64-pgo\python33stub.li
Stefan Krah added the comment:
> Preferably, the project files would be generated from the VS2010 project
> files, but for the moment, manually editing to make them work again might be
> fine as well.
Martin, Brian: Can I go ahead with vs-9.0.diff or would it interfere
with
Stefan Krah added the comment:
I also wonder how the buffer interface section can fail.
PyBuffer_ToContiguous() should translate to a simple memcpy()
for a bytes object. What is going on?
--
nosy: +skrah
___
Python tracker
<http://bugs.python.
Stefan Krah added the comment:
This is just a suggestion, but the easiest way of getting good support
for a non-mainstream platform is to provide a build slave:
http://www.python.org/dev/buildbot/
Setting up a build slave takes 20 min:
http://bugs.python.org/file24399/buildslave_install.txt
Stefan Krah added the comment:
I can confirm that test_distutils runs fine on Fedora both as root
and as non-root (rpmbuild is installed).
Also, I don't see any test failures when running the whole test suite
as root. IMO this means that all remaining issues in this report are
Changes by Stefan Krah :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue11954>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
This seems really out of date now. Closing.
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/iss
Stefan Krah added the comment:
See also #13072 and the discussion starting at:
http://mail.python.org/pipermail/python-dev/2012-March/117390.html
I think the priority should be "high", since the current behavior
doesn't preserve the status quo. Also, PEP-3118 suggests 'u&#
Stefan Krah added the comment:
Hmm, obviously the discussion starts here:
http://mail.python.org/pipermail/python-dev/2012-March/117376.html
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
I think the issue mentioned in eae7cc54d28b just occurred again:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6807/steps/test/logs/stdio
==
ERROR: test_module
Stefan Krah added the comment:
Brett, I reopened this because you said earlier that the test_reprlib
failure is due to a race condition where an invalidate_caches()
call is needed.
You're quite right of course that the new occurrence could be caused
by something unrelated. I can't
Stefan Krah added the comment:
You can't return mpd_realloc_dyn(result, nwords, status) in the
second instance: the coefficient must be initialized to zero
later on. So this is intentional.
--
components: +Extension Modules -Library (Lib)
resolution: -> invalid
stage: ->
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15059>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
I can see why it is seems strange that // and % behave differently.
If anything, I'd change divint to raise for things like inf // 3.
But the official test cases don't:
dvix601 divideint -Inf -1000 -> Infinity
remx701 remainder -Inf -
New submission from Stefan Krah :
The Ubuntu shared buildbot fails to run the tests:
using PTY: True
./python: error while loading shared libraries: libpython3.3dm.so.1.0: cannot
open shared object file: No such file or directory
make: *** [Python/importlib.h] Error 127
034c814eb187 was
Stefan Krah added the comment:
Rebuilding importlib.h fails:
--
Python/importlib.h needs to be rebuilt, but no interpreter
is available to do so. Leaving the previous version in
place. You may want to run ''make'' a se
Stefan Krah added the comment:
There's some unrelated stuff in the patch that reverts commits in
mpdecimal.c and multiprocessing. Maybe a Rietveld issue.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Mark has already said it all. -- Ken, I want to add that in the case
of _decimal it's pretty easy to test any suspected misbehavior against
decimal.py. This would have shown very quickly that there is n
Changes by Stefan Krah :
--
nosy: +brian.curtin, loewis
___
Python tracker
<http://bugs.python.org/issue15102>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
Looks like the FreeBSD bot fails in test_posix:
==
ERROR: test_fs_holes (test.test_posix.PosixTester)
--
Traceback (most recent
Stefan Krah added the comment:
> This looks like a bug in freebsd:
>
> http://lists.freebsd.org/pipermail/freebsd-amd64/2012-January/014332.html
I tested that one already yesterday (it was late, so I forgot to mention
it) and the test case attached to the bug report runs fine on the
Stefan Krah added the comment:
> int main(void)
> {
> int fd = open("ccc.c", O_RDONLY);
> off_t offset=lseek(fd,0,SEEK_HOLE);
> if (offset==-1) {
> if (errno==ENXIO) {
Darn, the errno in test_posix should be ENOTTY. Indeed, with ENOTTY the
test
Stefan Krah added the comment:
Martin v. L??wis wrote:
> > The debug build doesn't even *build*! That's the issue.
>
> It builds fine for me - I just tried.
What command line do you use? I tried:
C:\Users\stefan\pydev\cpython>.\Tools\buildbot\build-amd64
Stefan Krah added the comment:
I seem to be getting a functioning amd64 debug build by applying
the small useenv.diff and then running:
Tools\buildbot\build-amd64.bat
--
Added file: http://bugs.python.org/file26108/useenv.diff
___
Python tracker
Stefan Krah added the comment:
OK, I'll see if I find some time for the 2.7 docs.
--
assignee: -> skrah
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
I've fixed some paths in external-amd64.bat. Uploading a diff
instead of committing right away so as not to interfere with
the steadily incoming commits.
--
Added file: http://bugs.python.org/file26114/external-amd64
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Stefan, don't fear interfering. Merging is easy.
Good to know, I loathe merging. :)
--
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
All Windows buildbots are failing now:
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5):
error MSB3073: The command "cd
"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\"
[d:\cygwin\home\db3l\buil
Stefan Krah added the comment:
I'm trying out my suggestion on the 64-bit bot. Will revert if it
doesn't work out.
--
___
Python tracker
<http://bugs.python.o
1401 - 1500 of 3396 matches
Mail list logo
