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 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
Stefan Krah added the comment:
The fix would require all of these functions from memoryview.c (3.3):
last_dim_is_contiguous
cmp_structure
copy_base
copy_rec
copy_buffer
How to avoid code duplication? I could move them into abstract.c,
but conceptually they're really just low level b
Stefan Krah added the comment:
> You could move PyBuffer_ToContiguous() from abstract.c to memoryview.c.
For 3.3 that would be ideal, yes. I asked a while ago on python-dev
whether to backport the memoryview rewrite. The general mood was
against it.
So, for 2.7/3.2 I could add all th
Stefan Krah added the comment:
I think the original issue in parsetok.c is still present. The
fix that was committed was for sys_update_path().
--
___
Python tracker
<http://bugs.python.org/issue3
Stefan Krah added the comment:
There is an additional problem with PyBuffer_ToContiguous():
Suppose 'view' is multi-dimensional, C-contiguous and initialized
according to PyBUF_ND, i.e. view->shape != NULL but view->strides == NULL.
Now if PyBuffer_ToContiguous() i
New submission from Stefan Krah :
Using b127046831e2, I'm experiencing an import problem during the NumPy build.
I've reduced it to this scenario, which works in 3.2 but not in 3.3.
Note that in NumPy's setup.py, the equivalent of /home/stefan/tmp is
the first entry in sys.pat
Stefan Krah added the comment:
It looks like distutils/command from the stdlib is searched first
despite the fact that the first path entry is '/home/stefan/tmp'.
If distutils/command is replaced with a/b, the import works:
$ pwd
/home/stefan/tmp
$
$ ls a/b/
__init__.py x
Stefan Krah added the comment:
This is not a distutils issue. I want to know why this does not
throw an exception ...
python3.2 distutils/command/__init__.py
... while this raises ImportError:
~/usr/bin/python3.3 distutils/command/__init__.py
For the path structure please see my previous
Stefan Krah added the comment:
Argh. __init__.py was missing in the top directory. For some reason
Python 3.2 does not throw the error. Also, 3.3 does not raise in the
case of the a/b directory structure:
$ tree a
a
`-- b
|-- __init__.py
`-- xyz.py
$ ~/usr/bin/python3.3 a/b/__init__
Changes by Stefan Krah :
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue15295>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I think Serhiy has already explained that 43**10 is too large
to be represented exactly in 53-bit floating point arithmetic.
The math module wraps the floating point functions from the
C standard:
"It provides access to the mathematical functions defined b
Stefan Krah added the comment:
"Title" referring to the section header of
http://docs.python.org/dev/library/math.html ...
--
___
Python tracker
<http://bugs.python.o
Stefan Krah added the comment:
How about changing the title to something like:
math -- 53-bit floating point arithmetic
--
___
Python tracker
<http://bugs.python.org/issue15
Stefan Krah added the comment:
A quick question: Prior to this patch test_memoryview.py exercised
both mbuf_clear() and memory_clear(). Now gcov shows no coverage.
Is this expected? Is it still possible to construct tests that
exercise the code
Stefan Krah added the comment:
""Everywhere" is nowhere close to the truth. There are tons of
NOARGS functions which have the correct signature."
When I started writing C-extensions, I used the PyObject *unused
idiom. Then I saw Meador's version in so many places
Stefan Krah added the comment:
Here's a patch for 3.3, which consists mostly of tests. A couple of points:
o I removed the len > view->len check in PyBuffer_ToContiguous(), since
the function is not documented and silently accepting output buffers
that are too large seems
Stefan Krah added the comment:
Ramchandra Apte wrote:
> > [+1 for removing pow from the builtins and shunting three-argument pow to
> > the math module in Python 500.]
> Anybody who uses pow with three is doing something mathematical and has most
> likely imported math
Stefan Krah added the comment:
Sorry folks, I messed up the revisions when testing. This commit has
nothing to do with the decreased coverage.
Now I properly bisected and in r75481 mbuf_clear() and memory_clear()
are still covered, but in r75484 they are not.
r75484 addresses #1469629. I&#x
Stefan Krah added the comment:
r75484 should be b595e1ad5722.
--
___
Python tracker
<http://bugs.python.org/issue14930>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Any objections to committing this before beta2? What about the
len > view->len change: Does that look reasonable?
--
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Thanks, Nick! I'll move the function declaration back to abstract.h.
Waiting for Georg's input. -- It seems to me that #14330 is a blocker
that will only be fixed on Monday.
--
___
Python trac
Stefan Krah added the comment:
All right, 3.3 is fixed. Re-targeting for 3.2 and 2.7.
--
priority: release blocker -> normal
versions: +Python 3.1 -Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Stefan Krah added the comment:
Christian's posts and my initial report were about memoryview.tobytes(). It's
good that you changed the title: memoryview.tobytes() is more meaningful than
the slightly obscure PyBuffer_ToContiguous().
BTW, I'm sure that PyBuffer_FromC
Stefan Krah added the comment:
Nick, are you talking about a complete backport or just about pulling
in all functions needed by PyBuffer_ToContiguous()?
--
___
Python tracker
<http://bugs.python.org/issue12
Stefan Krah added the comment:
> Right now major parts of the buffer API are broken for non-trivial
> buffer definitions. IMHO a backport of the fix doesn't count as a new
> feature although it needs some new internal functions.
This particular bug fix for PyBuffer_ToContiguous(
Stefan Krah added the comment:
I can reproduce this exclusively with the pgupdate build:
msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=win32
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=win32
PCbuild\Win32-pgo\python.exe
Python 3.3.0b1 (default, Jul
New submission from Stefan Krah:
_decimal does not build in PGUpdate mode. I didn't notice this because
I've always used the Release mode so far:
msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=x64
msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platfor
Stefan Krah added the comment:
Martin v. L??wis wrote:
> > If not, then I doubt PGO is buying us anything anyway.
>
> It was originally added because people reported measurable speedups when
> profile-guided optimization is used, for VS 2008.
For libmpdec/64-bit I've measu
Stefan Krah added the comment:
_decimal-pgo.diff sort of solves the problem. It might be a good
idea to regenerate _decimal.vcproj using the GUI. I've created it
in true Unix fashion by modifying an existing vcproj...
I'm always building using the command line. If you say that the
Changes by Stefan Krah :
--
keywords: +needs review -patch
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue15511>
___
___
Py
Stefan Krah added the comment:
Using MSVC Professional 2010 and the GUI, I'm getting the same error:
1) Select PGInstrument|x64. Clean the solution.
2) Select PGUpdate|x64. Clean the solution.
3) Select PGInstrument|x64. Build the solution.
4) Select PGUpdate|x64. Build the sol
Stefan Krah added the comment:
Ok, Microsoft dropped PGO support in VS 2010 "Professional". In
VS 2008 *Professional* it was present.
So I'll jump through the hoops of the marketing department and
install "Ultimate".
The patch is of limited value then: _decimal does b
Stefan Krah added the comment:
Well, I have Ultimate now and encounter the same problem. Also, when
I start PCbuild\x64-pgi\python.exe it exits immediately without
displaying an error.
The PC\VS9.0 PGUpdate build works fine.
--
title: VS 2010 "Professional": _decimal does no
Stefan Krah added the comment:
Building from a fresh tree enables successful launching of
PCbuild\x64-pgi\python.exe,
but _decimal is still not built. I literally ran the following commands,
so anyone can paste them into a command window and see for themselves:
# cpython is a pristine clone
Stefan Krah added the comment:
Here's a patch based on the analysis. All test cases given here
now raise TypeError.
--
keywords: +patch
Added file: http://bugs.python.org/file26623/issue8847.diff
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
Antoine Pitrou wrote:
> I think we want to add those tests to the test suite as well.
What's a good place? Shall we just add one of the tests to test_tuple?
Also, the only person to run the tests with the PGO build will probably
be Martin just be
Stefan Krah added the comment:
New patches with tests for 3.2 and 3.3. For 3.2 I determined empirically
that EnableCOMDATFolding="1" (and not "0") turns on NOICF.
If anyone can confirm that this is the case or has a pointer to
the relevant vcproj docs, I'd be thrille
Changes by Stefan Krah :
Added file: http://bugs.python.org/file26633/issue8847-3.2.diff
___
Python tracker
<http://bugs.python.org/issue8847>
___
___
Python-bugs-list m
Changes by Stefan Krah :
Removed file: http://bugs.python.org/file26632/issue8847-3.3.diff
___
Python tracker
<http://bugs.python.org/issue8847>
___
___
Python-bugs-list m
Changes by Stefan Krah :
Added file: http://bugs.python.org/file26634/issue8847-3.3.diff
___
Python tracker
<http://bugs.python.org/issue8847>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Is it possible without too much effort to keep the old behavior
('u' -> Py_UNICODE)? Then I'd say that should go into 3.3.
The problem with the current behavior is that it's neither backwards
compatible nor PEP-3118 compliant.
If it is t
Stefan Krah added the comment:
The diff between b9558df8cc58 and default with array_revert_pep393.patch
applied is small, but I noticed that in some places you switched back to
Py_UNICODE typecode and in others not. For instance, in struct arraydescr
typecode is still char.
I'm not sur
Stefan Krah added the comment:
array_revert_pep393-2.patch looks good (checked against 7042a83f37e
and all following commits that should be kept).
--
___
Python tracker
<http://bugs.python.org/issue13
Stefan Krah added the comment:
A couple of days ago there was another effort by Ondřej Čertík to get
NumPy working with 3.3, see the thread starting here:
http://comments.gmane.org/gmane.comp.python.numeric.general/51087
I participated in that discussion and we hit the same problem with
the
Stefan Krah added the comment:
> There is a need to byte-swap only when the data is stored on disk in the
> reverse order from the native machine (i.e. NumPy is pointing to
> memory-mapped data).
In that case it should be a matter of disabling some NumPy unit tests.
It seems that
Changes by Stefan Krah :
--
nosy: +certik
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
I think math.isnan('snan') probably should not raise. Decimal('snan').is_nan()
just returns true and I am under the impression that IEEE 754 specifies the
same. I have to admit though that I just consulted Wikipedia for the latter:
&q
Stefan Krah added the comment:
Martin v. L??wis wrote:
> I don't mind that at all, either. What I dislike is "I have this issue,
> here is what I've got, and I will continue to work on it" kind of reports
> (when Dave clearly said that his patch is work-in-progr
Stefan Krah added the comment:
> OTOH, IEEE 754 *does* cover floating-point to int conversions (5.4.1, 5.8):
> those fall under 'general-computational operations', and as such should
> signal when given an sNaN.
That sounds good. Let's keep the ValueError
Stefan Krah added the comment:
> Why not add a is_nan() method to float numbers instead?
Do you mean replacing math.isnan(x) by x.is_nan() to avoid the issue
altogether? I'm not sure that's possible given that math just wraps
Stefan Krah added the comment:
Mark Dickinson wrote:
> Looks like we've got two separate issues here, that should probably be
> split into two separate bug reports. The first issue is that
> Decimal.__float__ is brain-dead when it comes to NaNs with payloads;
> I consider that
Stefan Krah added the comment:
I'm not against whitespace cleanup every now and then, but also -0
on a hook for C files. I think that (for C) the annoyance of having
a patch rejected because of trailing whitespace outweighs the
overall benefit.
--
nosy: +
1501 - 1600 of 3396 matches
Mail list logo
