Changes by stefan brunthaler :
Added file: http://bugs.python.org/file25543/20120510-vanilla-perf.txt
___
Python tracker
<http://bugs.python.org/issue14757>
___
___
Pytho
stefan brunthaler added the comment:
So I took a close look to what the performance problem was. Many of the
benchmarks used by the perf.py py3k benchmarks use function calls for which
there are no optimized derivatives available. In this case the function trying
to do the quickening (aptly
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 brunthaler :
Added file: http://bugs.python.org/file25586/20120514-inca.patch
___
Python tracker
<http://bugs.python.org/issue14757>
___
___
Python-bug
stefan brunthaler added the comment:
While looking at the instruction frequency traces, I noticed that INPLACE_*
instructions were not quickened to optimized instruction derivatives. The
submitted patch fixes this issue and correctly generates code performing the
substitution. The
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 brunthaler added the comment:
> Perhaps that's just me, but I find the performance gains rather limited given
> the sheer size of the changes.
Well there are a couple of things to keep in mind:
a) There is a substantial speedup potential in further interpretative
optimiz
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 M :
After issue7455 was fixed, a test was created to reflect the fix
(Lib/test/pickletester.py @ AbstractPickleModuleTests.test_bad_input). The test
makes sure that an UnpicklingError is raised whenever pickled data attempts to
pop on an empty stack.
Although tests
New submission from Stefan Krastanov :
>>> set.union(set([1,2]), [3])
set([1, 2, 3])
>>> set.union([1,2], [3])
TypeError: descriptor 'union' requires a 'set' object but received a 'list'
It seems a bit inconsistent. Is it justified somehow?
-
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
Stefan Krah added the comment:
Well, the path to python_d.exe looks right now, but Perl and nasm
aren't found:
"C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe"
build_ssl.py Release x64 -a
Found a working perl at 'C:\perl\bin\p
Stefan Krah added the comment:
Martin v. L??wis wrote:
> Even if it does work out it should be reverted. As HOST_PYTHON is not
> set, PythonExe should be computed correctly. So we really need to find
> out why it isn't.
Yes, of course. It's meant as a temporary measure to w
Stefan Krah added the comment:
> Well, the path to python_d.exe looks right now, but Perl and nasm
> aren't found:
>
>
> "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe"
> build_ssl.py Release x64 -a
>
>
Stefan Krah added the comment:
Jeremy Kloth wrote:
> nasm.exe was installed for myself (hence testing worked). I've now
> made it available to the buildbot account as well.
>
> Note that I have Perl installed but *not* on my PATH (on purpose).
> The patch supplied in iss
Stefan Krah added the comment:
Jeremy, your python-dev suggestion to move x64.props before pyproject.props
does not work for me. For instance, in python3dll.vcxproj:
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error
MSB3073: The comma
nd "cd C:\
Stefan Krah added the comment:
outdir.diff contains a solution that doesn't rely on HOST_PYTHON.
Works for both x64 and Win32.
Note that I've edited the files using Vim. -- I'm not sure if one can
even select Condition="'$(Platform)'=='Win32'" usin
New submission from Stefan Krah :
I'm getting this failure in test_email (Windows 64-bit build):
==
ERROR: test_localtime_epoch_notz_daylight_false (test_utils.Localtime
New submission from Stefan Krah :
[from #15102]
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7
--
components: Build
messages: 163847
nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, python-dev, skrah,
zach.ware
priority: normal
severity: normal
status
New submission from Stefan Krah :
[from #15102]
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.2
--
messages: 163848
nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, skrah, zach.ware
priority: normal
severity: normal
status: open
title: Fix 64-bit building
New submission from Stefan Krah :
[Antoine]
Ouch. The test failures on the buildbot now seem to point to problems with
OpenSSL's SHA1 implementation.
Jeremy, perhaps you can try to run the OpenSSL self-tests?
--
components: Tests
keywords: buildbot
messages: 163849
nosy: brian.c
Stefan Krah added the comment:
As far as I can see, the 3.3 buildbot scripts are fixed: After af1d98b7ca80
I can run Tools/buildbot/build.bat and Tools/buildbot/build-amd64.bat
successfully in any order.
I've run the tests, too, and I'm not getting the SHA1 failures.
As requested, I
Stefan Krah added the comment:
Well, as I said in the other issue, I can't reproduce. Apart from
running the self tests, perhaps delete the openssl directory and
start afresh?
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Antoine Pitrou wrote:
> Hmm, the buildbot fails compiling again after
> af1d98b7ca801049803d83a85bb8558f6e59f2a1:
>
> http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/139
I think it's unrelated (probably ssl mai
New submission from Stefan Krah :
I'm quite sure this worked before, but fails now:
C:\Users\stefan\pydev\cpython\PCbuild>amd64\python_d.exe -m test test_ssl
Traceback (most recent c
Stefan Krah added the comment:
Coincidentally, I've just asked the Solaris buildbot owner if he could
try out the system libffi. I'm not sure if even the latest libffi
supports suncc out of the box. Meador, did you get any answers on
libf
New submission from Stefan Krah :
suncc complains about negative values that are assigned to unsigned
char:
"Python/importlib.h", line 3634: warning: initializer does not fit or is out of
range: -125
"Python/importlib.h", line 3635: warning: initializer does not fit or is
Stefan Krah added the comment:
Jes??s Cea Avi??n wrote:
> Stefan, I am confused with your comments.
The FreeBSD bug report you linked to had a test case attached. The test case
uses errno == ENXIO. I could not reproduce the failure, so in my *first* comment
I questioned whether the failu
Stefan Krah added the comment:
The buildbot works with the HOST_PYTHON hack. Should we just leave
this as a permanent solution? -- I don't feel like touching the project
files for stable releases.
[%CD% should probably be quoted in the patch.]
--
components: +Build
resol
Changes by Stefan Krah :
--
nosy: +Justin.Venus
___
Python tracker
<http://bugs.python.org/issue12927>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
It worked out of the box for me. These are the versions I use:
# openssl version:
svn export http://svn.python.org/projects/external/openssl-1.0.1c
# nasm version (installer):
nasm-2.10.01-installer.exe
Let me see what I did:
cd openssl-1.0.1c
nmake -f ms
Stefan Krah added the comment:
The openssl self tests also pass here.
--
___
Python tracker
<http://bugs.python.org/issue15172>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Jeremy Kloth wrote:
> I've narrowed this down to a CPU capabilities issue with OpenSSL.
> What CPU are you using? I have a Q9450 (Core2 Quad)
Core 2 Duo E8500. But I run Windows under Linux/kvm/qemu, in case t
Stefan Krah added the comment:
+fprintf(outfile, "%d,", (unsigned int) data[i]);
Hmm, "%u"? :)
--
___
Python tracker
<http://bug
Stefan Krah added the comment:
Antoine Pitrou wrote:
> > +fprintf(outfile, "%d,", (unsigned int) data[i]);
> >
> > Hmm, "%u"? :)
>
> It doesn't change anything, since data[i] is between 0 and 255.
> (unless C `int` is 8 bits on
Stefan Krah added the comment:
My timezone is CET, so that fits your explanation. Indeed, the failure
also occurs on Windows 32-bit.
--
title: test_email: failure on Windows 64-bit -> test_email: failure on Windows
___
Python tracker
&l
Stefan Krah added the comment:
Antoine, is it possible to add --with-system-ffi to the build rules
of the Solaris/suncc bot? This will prevent the segfaults.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah added the comment:
Good that it works now. I've tagged this as a documentation issue.
--
assignee: -> docs@python
components: +Documentation -Tests
keywords: -buildbot
nosy: +docs@python
title: SHA1 failures on the 64-bit Windows buildbot -> Document nasm
Stefan Krah added the comment:
Looks similar to the sporadic test_reprlib failure. Roumen has explained
that here:
http://bugs.python.org/issue14599#msg162727
I didn't test myself though, just a guess.
--
___
Python tracker
Stefan Krah added the comment:
Did the Windows XP-4 bot start failing after 334ff92a8483 ?
The logs don't go back very far:
http://buildbot.python.org/all/builders/x86%20XP-4%203.2
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Ping. We have to decide if we need watchexp in _decimal. I've left it
out so far since all I can gather from the docs is that it somehow
behaves like _rescale.
Can we deprecate it and replace it by a proper rescale?
--
nosy: +georg.b
Stefan Krah added the comment:
In dbc94178703f it works again. Closing.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
watchexp was available in rescale() from the beginning ...
http://svn.python.org/view/sandbox/trunk/decimal/Decimal.py?revision=40721&view=markup
... and rescale() was renamed to quantize() in
http://svn.python.org/view/sandbox/trunk/decimal/Decima
New submission from Stefan Krah :
Unfortunately, this won't make it into 3.3. -- The self-review of mpdecimal.c
had priority and was extremely time consuming.
--
assignee: skrah
messages: 164469
nosy: lemburg, mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
Stefan Krah added the comment:
I've opened #15237 for the capsule API. I didn't add everyone to the
nosy list, since I suspect it's not of general interest.
--
___
Python tracker
<http://bugs.py
Stefan Krah added the comment:
The tests that fail in succession are these:
./python -m test -uall -v test_importlib test_import
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
If I comment out this, both tests run OK (I don't know if that
breaks anything else though):
diff --git a/Lib/importlib/test/test_api.py b/Lib/importlib/test/test_api.py
--- a/Lib/importlib/test/test_api.py
+++ b/Lib/importlib/test/test_api.py
@@ -172,7 +
Stefan Krah added the comment:
Given that --with-system-ffi works, I don't think we need the additional
burden of maintaining patches for libffi/suncc.
--
resolution: -> wont fix
stage: needs patch -> committed/rejected
status: ope
Stefan Behnel added the comment:
Looks like a new feature to me.
--
versions: +Python 3.4 -Python 3.3
___
Python tracker
<http://bugs.python.org/issue13
Stefan Behnel added the comment:
Florent, what you describe is exactly the definition of a new feature.
Users even have to change their code in order to make use of it.
--
___
Python tracker
<http://bugs.python.org/issue13
Stefan Krah added the comment:
Could you please state the Python version and line numbers in
memoryobject.c?
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
I see nothing wrong in memory_ass_sub(). In 2.7:
if (destbuf + bytelen < srcbuf || srcbuf + bytelen < destbuf)
/* No overlapping */
memcpy(destbuf, srcbuf, bytelen);
else
memmove(destbuf, srcbuf, bytelen);
Other versio
Stefan Krah added the comment:
I switched the algorithm in mpd_qsqrt() to the one from decimal.py.
Previously the square root was calculated in terms of 1/invsqrt(x).
Curiously enough this scheme _always_ seems to produce exact results
when expected, but I don't have a proof. I remember I
Stefan Krah added the comment:
Thanks, Amaury! -- "goto malloc_error" should not leak, because there's always
a jump to the "out" label in line 7563.
I use this idiom a lot ever since I saw it in several places in the Linux
kernel. Of cour
Stefan Krah added the comment:
I agree with Meador that this should be fixed upstream first.
There's a thread here on libffi-discuss, with a patch but no
conclusive answer:
http://sourceware.org/ml/libffi-discuss/2012/msg00168.html
--
___
P
Stefan Krah added the comment:
Ah, forget that: Alex has apparently already tested that patch.
--
___
Python tracker
<http://bugs.python.org/issue4130>
___
___
Stefan Krah added the comment:
Closing, since all 2.7 buildbots compile.
--
resolution: -> fixed
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/i
Changes by Stefan Krah :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15170>
___
___
Python-bugs-list mailing list
Unsubscri
Stefan Krah added the comment:
David, do you have an idea why the XP-4 3.2 machine fails the compile?
I can't reproduce this and I don't know if it's related to
334ff92a8483 or 177f93f0f5b9.
--
nosy: +db3l
___
Python tracker
<http
Stefan Krah added the comment:
The new test fails on the Fedora bot:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/2881/steps/test/logs/stdio
==
FAIL: test_copyxattr
Stefan Krah added the comment:
Thanks, David! I'll close this issue, perhaps the compile failures
on the Windows 7 buildbot can be sorted out separately.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
In Python 3.3 memoryobject.c is a complete rewrite. Porting the fix
separately would be quite a bit of work.
PyBuffer_ToContiguous(), which causes the problem in 2.7/3.2 and is
still broken in 3.3, could be fixed by using the recursive copy_buffer()
function
Changes by Stefan Mihaila :
--
nosy: +alexandre.vassalotti, ncoghlan, rhettinger
___
Python tracker
<http://bugs.python.org/issue15397>
___
___
Python-bugs-list m
2401 - 2500 of 4951 matches
Mail list logo
