cournapeau david added the comment:
Hi Martin,
It was nice meeting you at Pycon.
I finally took the time to set up a windows 64 bits environment, and here are
the exact steps I needed to do to reproduce the issue, and fix it by hand:
- Start fresh from windows 7 64 bits
- clone python
New submission from cournapeau david :
The following simple example:
setup.cfg
[global]
setup_hook = hooks.foo
and the following hooks.py file
def foo(content):
pass
Traceback (most recent call last):
File "../distutils2/distutils2/pysetup", line 5, in
main()
Fi
New submission from Cournapeau David :
If bdist_msi is used on a package which has a non released version
(defined from StrictVersion), it refuses to build the package. The code
for the bdist_msi mentions that pre-release is not supported. Knowing
nothing about msi, I don't know what sha
New submission from Cournapeau David :
cygwin compiler modules in distutils check versions of the toolchain,
and break is the version is not a released one.
I can't see the rationale for such a behavior, and it is particularly
annoying since it cannot be bypassed AFAIK. As it is the
Cournapeau David added the comment:
Ok, here is a patch which fixes the issue while retaining the AR
customization. Here is what it does:
- configure defines both AR and ARFLAGS in the configure script, and
those are used in the Makefile
- ARFLAGS is used instead of the harcoded rc (rc is
Cournapeau David added the comment:
You can see the traceback in this recent email:
http://mail.python.org/pipermail/python-list/2009-May/712106.html
--
___
Python tracker
<http://bugs.python.org/issue5
Cournapeau David added the comment:
The bug is also present in python 2.7a
--
versions: +Python 2.7, Python 3.0
___
Python tracker
<http://bugs.python.org/issue5
Cournapeau David added the comment:
Ok, it looks like following gcc 4.4.0 release, there is an installer for
the whole toolchain:
http://www.equation.com/servlet/equation.cmd?call=fortran
This installs gcc (C+Fortran+C++ compilers, the download is ~ 40 Mb),
and it can be used from the command
Cournapeau David added the comment:
The toolchain is difficult to build, but the patch is easy to review, it
just moves the MS_WIN64 outside the MS compiler specific part. If it
does not break the MS toolchain (the one used to build the official
python), I don't see the problem.
I can mak
Cournapeau David added the comment:
Both should be set as serious, in the sense that build_clib is totally
broken ATM, with no simple workaround. OTOH, maybe numpy is the only
user of build_clib, in which case it is not so serious (I use my own
fixed, copied versions of the original code for
Cournapeau David added the comment:
Hi Tarek,
Yes, I have a simple example, which show both 5940 and 5941 bugs:
"""
from distutils.core import setup
# How to install libfoo.a/foo.lib in say pkg_dir/lib ?
setup(name='yo', libraries=[('foo', {'sources
New submission from Cournapeau David :
The customize_compiler function is broken in python 3.1. The archiver
for a 'standard' unix compiler is set as ['ar', '-cr'], but in python
3.*, customize_compiler overwrites self.archiver from
get_sysconfig_var('AR'
New submission from Cournapeau David :
There is a bug in the function check_library_list. Assuming there are
some libraries in the distribution instance, the function checks that
lib[0] is a string, but the test checks exactly the contrary (line 137
of build_clib.py).
This is pretty serious, as
Cournapeau David added the comment:
Hi tarek,
I can't say for sure about the only part. My experience on windows is
that there are so many possible combinations that getting it right is
difficult.
But in any case, the raised exception is not helpful. I am a developer
and familiar
Cournapeau David added the comment:
I think compiling python itself with it would be quite difficult - I
have never attempted it. My 'scenario' is building extensions against
the official python for amd64 on windows.
The quickest way to test the patch would be as follows:
- tak
Cournapeau David added the comment:
Is there any change to see this integrated soon ? The patch is only a
couple of lines long,
thanks
--
___
Python tracker
<http://bugs.python.org/issue4
Cournapeau David added the comment:
@ Mark
Concerning float('inf') * 1j: you're right, my rambling did not make any
sense, sorry.
I agree that adding complexity may be a good reason to warrant an
arbitrary feature; actually, I did not manage to handle nan/inf at first
Cournapeau David added the comment:
> I disagree. *Why* do you think it should work? It fails for many other
> types:
I don't understand the rationale: why not making something work better
if possible ? Also, I don't understand the comparison with Decimal or
Fraction
Cournapeau David added the comment:
It is not really for an application, but for numpy. Of course, one can
always get around the problem - but since this is really a limitation
which can be easily fixed, why not fixing the problem :) ?
___
Python tracker
New submission from Cournapeau David :
On windows, with python 2.6, s = '%s' % float('inf') is 'inf', but s =
'%f' % float('inf') is equal to '1.#INF'.
This patch fixes the inconsistency, by using the code from floatobject.f
forma
Changes by Cournapeau David :
Removed file: http://bugs.python.org/file12502/nan_parse.patch
___
Python tracker
<http://bugs.python.org/issue2121>
___
___
Python-bug
Changes by Cournapeau David :
Removed file: http://bugs.python.org/file12503/nan_parse.patch
___
Python tracker
<http://bugs.python.org/issue2121>
___
___
Python-bug
Cournapeau David added the comment:
Ok, I found out how to make tests, and I found some problems while using
this on numpy. A third version of the patch, with unit tests: all tests
in test_complex.py pass.
Added file: http://bugs.python.org/file12504/nan_parse.patch
Cournapeau David added the comment:
> Nice-to-have but not a requirement that the entire input domain be
> supported.
Ok.
> It made sense for floats because of prevalence of use cases and
> because we wanted to match IEEE-754R as much as possible.
But why shouldn't this
Cournapeau David added the comment:
I disagree the feature is not needed, for several reasons:
- complex(repr(..)) roundtrip should work, whatever the value of complex is
- it is supported for float, so why not for complex ?
- I believe on the contrary it solves a very real problem
Cournapeau David added the comment:
Of course, I notice two bugs just after sending the patch... New patch
to fix those two issues (no check for closing bracket if opening ones
are there and a bug when only imaginary part is given).
Added file: http://bugs.python.org/file12503/nan_parse.patch
Cournapeau David added the comment:
I started a patch against the trunk to handle nan/inf/infinite (I have
not yet tackled the problem of negative zero).
The patch is a bit big, because I found the function quite difficult to
follow, so I refactored it a bit first (replacing the state machine
New submission from Cournapeau David :
I had some problems with python and universal builds related to the
WORDS_BIGENDIAN macro. Because universal builds are built in one pass
(one configure), the AC_C_ENDIAN cannot be used reliably. Example:
int main()
{
#ifdef WORDS_BIGENDIAN
printf(&quo
New submission from Cournapeau David :
I believe the current pyport.h for windows x64 has some problems. It
does not work for compilers which are not MS ones, because building
against the official binary (python 2.6) relies on features which are
not enabled unless MS_WIN64 is defined, and the
New submission from Cournapeau David <[EMAIL PROTECTED]>:
This patch if the first part to follow discussion on python-list
concerning problems when using distutils.config.try_run with mingw and
manifest problems on windows for python 2.6 (or any python built with
recent VS).
It simpl
New submission from Cournapeau David <[EMAIL PROTECTED]>:
I tried to build some extensions with python 2.6 (built from sources
with VS 2008 express), and got some errors in the function
query_vcvarsall. The offending lines are:
if len(result) != len(interesting):
raise ValueError(st
Cournapeau David <[EMAIL PROTECTED]> added the comment:
It's not that I don't want to work on it, but I don't know anything
about msi, except that some windows users of my packages request it :)
So I would need some indication on what to fix exactly
Do I understand right t
Cournapeau David <[EMAIL PROTECTED]> added the comment:
Ok, thanks for the information.
It may good to have a bit more informative error, though, such as saying
which characters are allowed when checking against a regex ?
__
Tracker <[EMAIL PROTECTE
New submission from Cournapeau David <[EMAIL PROTECTED]>:
Hi,
I wanted to build a msi using the build_msi distutils command for one of
my package, but at some point, it fails, at the function make_id, at
line 177 in mstlib/__init__.py, for a file named aixc++.py. The regex
indeed refus
34 matches
Mail list logo