headers
Robert Pickle | 1 Nov 2007 17:32
Favicon

disutils related bug when building scipy via svn

hello,

i'm having some trouble building scipy from subversion. here's the 
relevant output:

  building library "statlib" sources
Traceback (most recent call last):
   File "setup.py", line 92, in <module>
     setup_package()
   File "setup.py", line 84, in setup_package
     configuration=configuration )
   File "/usr/lib/python2.5/site-packages/numpy/distutils/core.py", line 
176, in setup
     return old_setup(**new_attr)
   File "distutils/core.py", line 151, in setup
   File "distutils/dist.py", line 974, in run_commands
   File "distutils/dist.py", line 994, in run_command
   File 
"/usr/lib/python2.5/site-packages/numpy/distutils/command/install.py", 
line 16, in run
     r = old_install.run(self)
   File "distutils/command/install.py", line 506, in run
   File "/usr/lib/python2.5/cmd.py", line 333, in run_command
     del help[cmd]
   File "distutils/dist.py", line 994, in run_command
   File "distutils/command/build.py", line 113, in run
   File "/usr/lib/python2.5/cmd.py", line 333, in run_command
     del help[cmd]
   File "distutils/dist.py", line 994, in run_command
   File
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nils Wagner | 5 Nov 2007 08:14
Picon

ImportError: No module named distutils.ccompiler

Hi all,

I cannot install the latest svn version of numpy (r4380).
I am using python2.3 on x86_64.

python setup.py install --prefix=$HOME/local
Running from numpy source directory.
Traceback (most recent call last):
   File "setup.py", line 90, in ?
     setup_package()
   File "setup.py", line 62, in setup_package
     from numpy.distutils.core import setup
   File 
"/data/home/nwagner/svn/numpy/numpy/distutils/__init__.py", 
line 6, in ?
     import ccompiler
   File 
"/data/home/nwagner/svn/numpy/numpy/distutils/ccompiler.py", 
line 6, in ?
     from distutils.ccompiler import *
ImportError: No module named distutils.ccompiler

Nils
Permalink | Reply | 1 comment |
headers
Robert Kern | 5 Nov 2007 17:05
Picon
Gravatar

Re: ImportError: No module named distutils.ccompiler

Nils Wagner wrote:
> Hi all,
> 
> I cannot install the latest svn version of numpy (r4380).
> I am using python2.3 on x86_64.
> 
> python setup.py install --prefix=$HOME/local
> Running from numpy source directory.
> Traceback (most recent call last):
>    File "setup.py", line 90, in ?
>      setup_package()
>    File "setup.py", line 62, in setup_package
>      from numpy.distutils.core import setup
>    File 
> "/data/home/nwagner/svn/numpy/numpy/distutils/__init__.py", 
> line 6, in ?
>      import ccompiler
>    File 
> "/data/home/nwagner/svn/numpy/numpy/distutils/ccompiler.py", 
> line 6, in ?
>      from distutils.ccompiler import *
> ImportError: No module named distutils.ccompiler

Do you have the appropriate python-dev/python-devel package installed?

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pierre GM | 6 Nov 2007 22:07
Picon

From F90 to F77

All,

A few months ago, I wrote a small scipy package calling some Fortran 90 code. 
Everything went fine until we tried to compile the package with g77, where 
the compiler choked on the slices and FLOOR that were present in the code. 
Rewriting the F90 code to get rid of the slices was easy, but I wouldn't want 
to mess with FLOOR.

What would be the best approach to have access to FLOOR during the build ?

Thanks a lot for any comment/suggestions.
P.
Permalink | Reply | 3 comments |
headers
John Travers | 6 Nov 2007 22:26
Picon
Gravatar

Re: From F90 to F77

On Tue, 2007-11-06 at 16:07 -0500, Pierre GM wrote:
> All,
> 
> A few months ago, I wrote a small scipy package calling some Fortran 90 code. 
> Everything went fine until we tried to compile the package with g77, where 
> the compiler choked on the slices and FLOOR that were present in the code. 
> Rewriting the F90 code to get rid of the slices was easy, but I wouldn't want 
> to mess with FLOOR.
> 
> What would be the best approach to have access to FLOOR during the build ?
> 

Why not just use gfortran? g77 is no longer maintained for several years
whereas gfortran is under very active development and should compile all
f95/f90/f77 code and even have compatibility with many of g77s bugs (err
features).

Best regards,
John
Permalink | Reply | 2 comments |
headers
Pierre GM | 6 Nov 2007 22:40
Picon

Re: From F90 to F77


> Why not just use gfortran?

Well, I use gfortran myself, but the colleague who's trying to install that 
particular package still relies on g77. Seems that as blas was compiled with 
g77, g77 is the compiler called by default during the setup...

So, is there a way to force one particular executable to be used ? Preferably 
in a way transparent to the user ?
Permalink | Reply | 0 comments |
headers
David Cournapeau | 7 Nov 2007 03:58
Picon
Picon

Re: From F90 to F77

John Travers wrote:
> On Tue, 2007-11-06 at 16:07 -0500, Pierre GM wrote:
>   
>> All,
>>
>> A few months ago, I wrote a small scipy package calling some Fortran 90 code. 
>> Everything went fine until we tried to compile the package with g77, where 
>> the compiler choked on the slices and FLOOR that were present in the code. 
>> Rewriting the F90 code to get rid of the slices was easy, but I wouldn't want 
>> to mess with FLOOR.
>>
>> What would be the best approach to have access to FLOOR during the build ?
>>
>>     
>
> Why not just use gfortran? g77 is no longer maintained for several years
> whereas gfortran is under very active development and should compile all
> f95/f90/f77 code and even have compatibility with many of g77s bugs (err
> features).
>   
g77 is still used as the default fortran compiler in major distributions 
(ubuntu and debian, for example), and g77 is not ABI compatible with 
gfortran without a lot of efforts.

cheers,

David
Permalink | Reply | 0 comments |
headers
Jarrod Millman | 8 Nov 2007 01:21
Picon
Favicon
Gravatar

ANN: NumPy 1.0.4

I'm pleased to announce the release of NumPy 1.0.4.

NumPy is the fundamental package needed for scientific computing with
Python.  It contains:

    * a powerful N-dimensional array object
    * sophisticated (broadcasting) functions
    * basic linear algebra functions
    * basic Fourier transforms
    * sophisticated random number capabilities
    * tools for integrating Fortran code.

Besides it's obvious scientific uses, NumPy can also be used as an
efficient multi-dimensional container of generic data. Arbitrary
data-types can be defined. This allows NumPy to seamlessly and
speedily integrate with a wide-variety of databases.

This is largely a bug fix release with one notable improvements:

- The NumPy and SciPy developers have decided to adopt the Python
naming convention for classes. So as of this  release, TestCase
classes may now be prefixed with either 'test' or 'Test'.  This will
allow us to write TestCase classes using the CapCase words, while
still accepting the old style names.

For information, please see the release notes:
http://sourceforge.net/project/shownotes.php?release_id=552568&group_id=1369

Thank you to everybody who contributed to the recent release.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthieu Brucher | 8 Nov 2007 09:21
Picon

Re: ANN: NumPy 1.0.4

Excellent !
I just tried it on a Windows box (the Python 2.5 package), it works without anychanges (besides the changes in NumpyTest).

Matthieu

2007/11/8, Jarrod Millman < millman <at> berkeley.edu>:
I'm pleased to announce the release of NumPy 1.0.4.

NumPy is the fundamental package needed for scientific computing with
Python.  It contains:

    * a powerful N-dimensional array object
    * sophisticated (broadcasting) functions
    * basic linear algebra functions
    * basic Fourier transforms
    * sophisticated random number capabilities
    * tools for integrating Fortran code.

Besides it's obvious scientific uses, NumPy can also be used as an
efficient multi-dimensional container of generic data. Arbitrary
data-types can be defined. This allows NumPy to seamlessly and
speedily integrate with a wide-variety of databases.

This is largely a bug fix release with one notable improvements:

- The NumPy and SciPy developers have decided to adopt the Python
naming convention for classes. So as of this  release, TestCase
classes may now be prefixed with either 'test' or 'Test'.  This will
allow us to write TestCase classes using the CapCase words, while
still accepting the old style names.

For information, please see the release notes:
http://sourceforge.net/project/shownotes.php?release_id=552568&group_id=1369

Thank you to everybody who contributed to the recent release.

Enjoy,

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev



--
French PhD student
Website : http://miles.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher 
_______________________________________________
Scipy-dev mailing list
Scipy-dev <at> scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev
Permalink | Reply | 0 comments |
headers
Jarrod Millman | 13 Nov 2007 07:09
Picon
Favicon
Gravatar

I removed some duplicate code from weave

Hey,

I just noticed that dumb_shelve.py and dumbdbm_patched.py were in both
scipy.io and scipy.weave.  Since I assume that this was just an
oversight, I went ahead and cleaned it up.  First, I made sure that
the newest code was in scipy.io:
  http://projects.scipy.org/scipy/scipy/changeset/3521
  http://projects.scipy.org/scipy/scipy/changeset/3522
And then I removed the version in scipy.weave:
  http://projects.scipy.org/scipy/scipy/changeset/3524

Please let me know if this change causes any major problems.

Cheers,

--

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
Permalink | Reply | 0 comments |

Gmane