#9808: Upgrade numpy to 1.4.1 and scipy to 0.8
----------------------------------------------------------------------------------+
Reporter: maldun
| Owner: maldun
Type: task
| Status: needs_review
Priority: major
| Milestone: sage-4.6
Component: packages
| Keywords: numpy, scipy
Author: Stefan Reiterer, Francois Bissey
| Upstream: N/A
Reviewer: Karl-Dieter Crisman, David Kirkby, Leif Leonhardy, Francois
Bissey | Merged:
Work_issues:
|
----------------------------------------------------------------------------------+
Comment(by fbissey):
Replying to [comment:142 maldun]:
> Replying to [comment:141 leif]:
> > Dave pointed me to this ticket the day before yesterday (and I read it
from the beginning). ;-)
> >
> > Despite that, it's unclear to me which diffs are currrent, and the
description should IMHO be updated wrt. what's to be done to review this.
> >
> > {{{./sage -ba}}} is also in my opinion not a solution to get dependent
extension modules updated, i.e. if {{{./sage -b}}} isn't sufficient,
dependencies should be added to {{{module_list.py}}}.
> >
>
> I cleaned up the discription a little bit, and deleted the obsolete
remark about networkx-1.2
>
> I don't know if this is a good Idea because this is a whole bunch of
files we are talking about, which have to be added. Perhaps you won't save
much time either when compiling. I first tried this too, but after about 2
hours searching, I got somehow tired of this... And after merging numpy >
1.3.x into Sage this has not to be done anymore. All versions of 1.5.x
builded without problems, and didn't need -ba anymore.
> You only have to do this when big changes are happening, and this is
rather occassionally.
>
> package with a linux ppc patch is out: http://code.google.com/p/spkg-
upload/downloads/detail?name=numpy-1.4.1.p0.spkg
> hope it works this time!
Ok so I tried to build numpy-1.4.1 with our patch on ppc. Didn't work.
It may be a good start but it fails in the same way it did before:
{{{
[39mcompile options: '-Inumpy/core/src/private -Inumpy/core/src
-Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray
-Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.6
-c' [0m
[39mpowerpc-unknown-linux-gnu-gcc: _configtest.c [0m
[39mremoving: _configtest.c _configtest.o [0m
Traceback (most recent call last):
File "setup.py", line 187, in <module>
setup_package()
File "setup.py", line 180, in setup_package
configuration=configuration )
File "/scratch/portage/portage/dev-
python/numpy-1.4.1/work/numpy-1.4.1/numpy/distutils/core.py", line 186, in
setup
return old_setup(**new_attr)
File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/scratch/portage/portage/dev-
python/numpy-1.4.1/work/numpy-1.4.1/numpy/distutils/command/build.py",
line 37, in run
old_build.run(self)
File "/usr/lib/python2.6/distutils/command/build.py", line 134, in run
self.run_command(cmd_name)
File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/scratch/portage/portage/dev-
python/numpy-1.4.1/work/numpy-1.4.1/numpy/distutils/command/build_src.py",
line 152, in run
self.build_sources()
File "/scratch/portage/portage/dev-
python/numpy-1.4.1/work/numpy-1.4.1/numpy/distutils/command/build_src.py",
line 169, in build_sources
self.build_extension_sources(ext)
File "/scratch/portage/portage/dev-
python/numpy-1.4.1/work/numpy-1.4.1/numpy/distutils/command/build_src.py",
line 328, in build_extension_sources
sources = self.generate_sources(sources, ext)
File "/scratch/portage/portage/dev-
python/numpy-1.4.1/work/numpy-1.4.1/numpy/distutils/command/build_src.py",
line 385, in generate_sources
source = func(extension, build_dir)
File "numpy/core/setup.py", line 416, in generate_config_h
rep = check_long_double_representation(config_cmd)
File "numpy/core/setup_common.py", line 136, in
check_long_double_representation
type = long_double_representation(pyod(object))
File "numpy/core/setup_common.py", line 244, in
long_double_representation
raise ValueError("Unrecognized format (%s)" % saw)
ValueError: Unrecognized format (['001', '043', '105', '147', '211',
'253', '315', '357', '301', '235', '157', '064', '124', '000', '000',
'000', '000', '000', '000', '000', '000', '000', '000', '000', '376',
'334', '272', '230', '166', '124', '062', '020'])
[31;01m* [0m ERROR: dev-python/numpy-1.4.1 failed:
}}}
The expectation from numpy/core/setup_common.py is:
{{{
LONG_DOUBLE_REPRESENTATION_SRC = r"""
/* "before" is 16 bytes to ensure there's no padding between it and "x".
* We're not expecting any "long double" bigger than 16 bytes or with
* alignment requirements stricter than 16 bytes. */
typedef %(type)s test_type;
struct {
char before[16];
test_type x;
char after[8];
} foo = {
{ '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0',
'\001', '\043', '\105', '\147', '\211', '\253', '\315', '\357'
},
-123456789.0,
{ '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' }
};
"""
}}}
And when you compare the two you can see that it is an endianess problem.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9808#comment:162>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
