numpy-discussion — Discussion list for all users of Numerical Python

[Numpy-discussion] Passing numpy arrays to matlab

[Josh M. <jos...@gm...>]

Hi David,

Did you have a look at mlabwrap? It's quite hard to find on the net,  
which is a shame, since it is a much more up to date version,  
enhancing pymat with the things that you are trying to do. It allows  
passing arrays and getting arrays back.

http://mlabwrap.sourceforge.net/

However, I do agree with you that it would be good to have a bridge  
based on ctypes. I can't really help since I long ago moved all of my  
code from Matlab to Numpy and Matplotlib.

Cheers,
Josh M

David Cournapeau <da...@ar...> wrote:
>
> Hi,
>
>     I am trying to find a nice way to communicate between matlab and
> python. I am aware of pymat, which does that, but the code is
> deprecated, and I thing basing the code on ctypes would lead to much
> more robust code.
>
>     http://claymore.engineer.gvsu.edu/%7Esteriana/Software/pymat.html
>
> I have a really simple prototype which can send and get back data from
> matlab, but I was wondering if it would be possible to use a scheme
> similar to ctypes instead of having to convert it by hand. Let me
> present the way communication with matlab is done:
>
>     - open a matlab session, which on unix launch a matlab process,  
> and
> set up pipes between the calling process and matlab process for
> communication
>     - To send data from the calling process to matlab, you first  
> have to
> create a mxArray, which is the basic matlab handler of a matlab array,
> and populating it. Using mxArray is very ackward : you cannot create
> mxArray from existing data, you have to copy data to them, etc...  
> (it is
> one of the reason I started looking in python in the first place:
> interfacing matlab with foreign code is really not a nice experience,
> and the API is not rich enough to do many interesting things; I am
> actually amazed how poor this part of matlab is, a product which is  
> now
> 20 years old).
>
>     I was wondering if there was a way to extend a numpy array so  
> that I
> could send directly numpy arrays to matlab C functions expecting a ,
> with ctypes doing the hard work. For example, now, to send data to
> matlab, I do:
>
>     session   = MatlabEngine()
>     # data is a numpy array, 'dataname' a string with its name inside
> matlab interpreter
>     session.put(data, 'dataname')
>
> The put function has do to a lot for work:
>     - first, getting metadata from data (dimensions, real or complex,
> etc...)
>     - then creating a mxArray with the same metadata
>     - then populating the mxarray by copying the data from the  
> numpy array.
>
> And of course, taking care that all mxarrays are detroyed, otherwise,
> memory leak... That's why I was thinking about something a bit  
> smarter:
> creating a mxarray class which implements the numpy interface. I could
> create a mxarray from a numpy array easily, send a mxarray directly  
> to C
> function with ctypes, etc... Is this doable ? Would this take care of
> correct destruction of mxarrays ? I really don't know much about the
> internals of numpy arrays, so I don't really know how to start,
>
>     cheers,
>
>     David
>
>

Re: [Numpy-discussion] Passing numpy arrays to matlab

[Andrew S. <str...@as...>]

David Cournapeau wrote:
>     - To send data from the calling process to matlab, you first have to 
> create a mxArray, which is the basic matlab handler of a matlab array, 
> and populating it. Using mxArray is very ackward : you cannot create 
> mxArray from existing data, you have to copy data to them, etc... 
My understanding, never having done it, but from reading the docs, is
that you can create a "hybrid array" where you manage the memory. Thus,
you can create an mxArray from existing data. However, the docs
basically say that this is too hard for most mortals (and they may well
be right -- too painful for me, anyway)!

Re: [Numpy-discussion] ctypes warning

[Andrew S. <str...@as...>]

Stefan van der Walt wrote:
> On Mon, Nov 06, 2006 at 02:09:32PM -0600, John Hunter wrote:
>   
>> A simple import of numpy with the latest svn triggers a ctypes warning
>>
>> In [1]: import numpy
>> /usr/lib/python2.4/site-packages/numpy/ctypeslib.py:12: UserWarning:
>> All features of ctypes interface may not work with ctypes < 1.0.1
>>   warnings.warn("All features of ctypes interface may not work with "
>>  
>>
>> This is a bit of an annoyance.  Even if the warning level is
>> configurable, I think the bulk of matplotlib users, who get the
>> warning when using numpy through mpl but make no use of ctypes, will
>> be confused by this.  Is it right and good that this message gets
>> triggered by default for any import of numpy, even those not using the
>> ctypes features?
>>     
>
> I moved the warning to inside ctypeslib.load_library.  I think most
> people using ctypes in numpy come via that route. 
I don't come in via that route. How hard is it to trigger on a getattr()
for the .ctypes attribute?

[Numpy-discussion] Passing numpy arrays to matlab

[David C. <da...@ar...>]

Hi,

    I am trying to find a nice way to communicate between matlab and 
python. I am aware of pymat, which does that, but the code is 
deprecated, and I thing basing the code on ctypes would lead to much 
more robust code.

    http://claymore.engineer.gvsu.edu/%7Esteriana/Software/pymat.html

I have a really simple prototype which can send and get back data from 
matlab, but I was wondering if it would be possible to use a scheme 
similar to ctypes instead of having to convert it by hand. Let me 
present the way communication with matlab is done:

    - open a matlab session, which on unix launch a matlab process, and 
set up pipes between the calling process and matlab process for 
communication
    - To send data from the calling process to matlab, you first have to 
create a mxArray, which is the basic matlab handler of a matlab array, 
and populating it. Using mxArray is very ackward : you cannot create 
mxArray from existing data, you have to copy data to them, etc... (it is 
one of the reason I started looking in python in the first place: 
interfacing matlab with foreign code is really not a nice experience, 
and the API is not rich enough to do many interesting things; I am 
actually amazed how poor this part of matlab is, a product which is now 
20 years old).

    I was wondering if there was a way to extend a numpy array so that I 
could send directly numpy arrays to matlab C functions expecting a , 
with ctypes doing the hard work. For example, now, to send data to 
matlab, I do:

    session   = MatlabEngine()
    # data is a numpy array, 'dataname' a string with its name inside 
matlab interpreter
    session.put(data, 'dataname')

The put function has do to a lot for work:
    - first, getting metadata from data (dimensions, real or complex, 
etc...)
    - then creating a mxArray with the same metadata
    - then populating the mxarray by copying the data from the numpy array.

And of course, taking care that all mxarrays are detroyed, otherwise, 
memory leak... That's why I was thinking about something a bit smarter: 
creating a mxarray class which implements the numpy interface. I could 
create a mxarray from a numpy array easily, send a mxarray directly to C 
function with ctypes, etc... Is this doable ? Would this take care of 
correct destruction of mxarrays ? I really don't know much about the 
internals of numpy arrays, so I don't really know how to start,

    cheers,

    David

[Numpy-discussion] VisIt Usage at LLNL

[<dl...@ll...>]

Paul Dubois asked me to post a short summary about how VisIt is used
at LLNL.

First, I am not a VisIt developer, but I have worked with it and those
who use it in day to day work.  I have also used it to generate high
resolution movies of medium to extremely large (~ 4 TeraByte) data sets.

VisIt is based on VTK (Visualization Tool Kit, check their webpage via
google search).  However, several features have been re-implemented for
performance reasons or because they did (or do not) exist in VTK.

VisIt is open source, but at present time does not have a true open source
development model (no sourceforge home page for example).  This may change in
the future, but I recommend contacting the VisIt team directly to find out
about official plans in this direction.

>From my perspective, VisIt is used in three ways at LLNL:
   1) Debugging    (GUI-based, but could use the Python interface)
   2) Exploration  (GUI-based)
   3) Movies       (Usually heavier use of the python interface)

Debugging:

    VisIt contains many operators that can be used to find bad cells and and
    display information about them.  A typical debugging session might start
    with a bad zonal quantity.  The user first creates plots of fields of
    interest using pseudocolor plots for example.  Then the user applies an
    OnionPeel operator and enters the domain and zone number from the error
    message generated by the code.  The user can then vary the number of
    additional layers of cells displayed around the bad cell.
    Finally, this small set of cells can be picked or queried, and investigated
    at different time steps.

    VisIt can also plot various quantities over time.  The expression engine
    in VisIt can be used to compute many derived quantities.

    VisIt also handles cells containing multiple materials in a robust way.

    There is interest in having physics codes dump Python
    scripts for VisIt that would automatically visualize errors in
    simulations.

Exploration:

    VisIt supports a large set of expressions, including the expected
    arithmetic operations along with vector operations (cross, dot, etc.),
    conditional operations (if-then-else), and many other useful functions.
    This allows users to create a large set of derived fields and then
    interact with them in VisIt like any other field.  I have seen users
    generate quite interesting plots by carefully creating derived quantities
    from the raw simulation dump files.

    VisIt has a nice set of functionality for creating 2-D plots.

Movies:

    The way I typically approach the problem of generating a movie of a given
    visualization with a static view-point is as follows.

    1) First I set up the visualization with the domain scientist(s).  This
       process is iterative by nature and is entirely GUI based.  VisIt can save
       'session' files that record everything about a given session, allowing me
       to create multiple visualizations and re-use them later.

    2) Once everything is set up, VisIt can generate the movie from within
       the GUI, or the session file can be used in a python script to drive
       VisIt.  I usually use the Python interface because that gives direct
       control over camera position and other features.  For large movies,
       the frames must be generated on a cluster and the batch system is
       necessary.  Python can be used to build scripts that play nice with
       the batch-system at LLNL.

    It is also possible to build an entire movie using Python by specifying
    exactly which operations to apply.  The end-result is a self-contained
    script for generating frames.  However, this is a labor intensive
    approach and is only needed for movies with complex camera movements or
    other effects.  Even for such movies, VisIt has a key-framing system
    that can handle some common cases for movies.

For more information I suggest emailing the VisIt team directly at:
vis...@ll...

Regards

Re: [Numpy-discussion] Strange and hard to reproduce crash

[Fernando P. <fpe...@gm...>]

On 10/23/06, Travis Oliphant <oli...@ie...> wrote:

> I've placed them in SVN (r3384):
>
> arraydescr_dealloc needs to do something like.
>
> if (self->fields == Py_None) {
>     print something
>     incref(self)
>     return;
> }

Travis, I know you're busy right now, so this message is just so that
the archives have this info, for whenever you revisit the problem.

A long run of our code is now producing the following output:

*** Reference count error detected:
an attempt was made to deallocate 12 (d) ***
*** Reference count error detected:
an attempt was made to deallocate 12 (d) ***

etc.

Thanks to your changes it does not crash anymore, so it's not a big
deal for us.  Whenever you want further details, I can try to collect
them.

Regards,

f

Re: [Numpy-discussion] Style - was Re: numpy.repeat TypeError: array cannot be safely cast to required type

[Victoria G. L. <la...@st...>]

Stefan van der Walt wrote:
> On Mon, Nov 06, 2006 at 03:10:20PM -0500, Colin J. Williams wrote:
>   
>> Many thanks.  In general, there is sense in the Python dictum about having one
>> way to do things.  Although, in this case [length] vs length for one dimension
>> doesn't
>> exercise me greatly.  I would be a bit more concerned about synonyms.
>>
>> Nobody has proposed using English yet - zeroes.
>>     
>
> If Cambridge Advanced Learner's is happy with zeros, then so we should
> be:
>
> http://dictionary.cambridge.org/define.asp?key=92164&dict=CALD
>
> zero   Show phonetics
> noun plural zeros or zeroes
> 1 [C or U] (the number) 0; nothing:
>
> I think the American-english speakers on the list outnumber the rest
> of us, so we'd better be careful :)
>   
You know, I spell this wrong at least every other time I use it.
But of course, if we changed it to "zeroes", I'd -still- spell it wrong 
every other time I used it.

Are synonyms really *always* evil????

wistfully,
Vicki Laidler

[Numpy-discussion] Scholarly contribution of NumPy : request for review

[Travis O. <oli...@ee...>]

I apologize for this bit of spam.

If there is anyone on this list (preferrably of Associate Professor or 
similar rank) who can provide an honest assessment of the scholarly 
contribution of NumPy and/or SciPy (and has not already done so)? 

If you can do this and don't mind me quoting you to a tenure-review 
committee, could you please email me your assessment by Friday morning 
(Nov. 10).   Please include information about your position in the 
mail.  I welcome all assessments (both positive and negative). 

Thank you very much.


Travis Oliphant
Assistant Professor
Brigham Young University
oli...@ee...
801-422-3108

Re: [Numpy-discussion] Style - was Re: numpy.repeat TypeError: array cannot be safely cast to required type

[Stefan v. d. W. <st...@su...>]

On Mon, Nov 06, 2006 at 03:10:20PM -0500, Colin J. Williams wrote:
> Many thanks.  In general, there is sense in the Python dictum about hav=
ing one
> way to do things.  Although, in this case [length] vs length for one di=
mension
> doesn't
> exercise me greatly.  I would be a bit more concerned about synonyms.
>=20
> Nobody has proposed using English yet - zeroes.

If Cambridge Advanced Learner's is happy with zeros, then so we should
be:

http://dictionary.cambridge.org/define.asp?key=3D92164&dict=3DCALD

zero   Show phonetics
noun plural zeros or zeroes
1 [C or U] (the number) 0; nothing:

I think the American-english speakers on the list outnumber the rest
of us, so we'd better be careful :)

Cheers
St=E9fan

Re: [Numpy-discussion] Style - was Re: numpy.repeat TypeError: array cannot be safely cast to required type

[Charles R H. <cha...@gm...>]

On 11/6/06, Colin J. Williams <cj...@sy...> wrote:
<snip>

Nobody has proposed using English yet - zeroes.
>

It seemed a bridge too far.

Chuck

Re: [Numpy-discussion] ctypes warning

[Stefan v. d. W. <st...@su...>]

On Mon, Nov 06, 2006 at 02:09:32PM -0600, John Hunter wrote:
>=20
> A simple import of numpy with the latest svn triggers a ctypes warning
>=20
> In [1]: import numpy
> /usr/lib/python2.4/site-packages/numpy/ctypeslib.py:12: UserWarning:
> All features of ctypes interface may not work with ctypes < 1.0.1
>   warnings.warn("All features of ctypes interface may not work with "
> =20
>=20
> This is a bit of an annoyance.  Even if the warning level is
> configurable, I think the bulk of matplotlib users, who get the
> warning when using numpy through mpl but make no use of ctypes, will
> be confused by this.  Is it right and good that this message gets
> triggered by default for any import of numpy, even those not using the
> ctypes features?

I moved the warning to inside ctypeslib.load_library.  I think most
people using ctypes in numpy come via that route.  Soon, we can remove
the warning, but for now I think it should remain -- the bugs
resulting from using older versions of ctypes are fairly hard to track
down.

Regards
St=E9fan

[Numpy-discussion] ctypes warning

[John H. <jdh...@ac...>]

A simple import of numpy with the latest svn triggers a ctypes warning

In [1]: import numpy
/usr/lib/python2.4/site-packages/numpy/ctypeslib.py:12: UserWarning:
All features of ctypes interface may not work with ctypes < 1.0.1
  warnings.warn("All features of ctypes interface may not work with "
 

This is a bit of an annoyance.  Even if the warning level is
configurable, I think the bulk of matplotlib users, who get the
warning when using numpy through mpl but make no use of ctypes, will
be confused by this.  Is it right and good that this message gets
triggered by default for any import of numpy, even those not using the
ctypes features?

JDH

Re: [Numpy-discussion] Style - was Re: numpy.repeat TypeError: array cannot be safely cast to required type

[Colin J. W. <cj...@sy...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Tim Hochberg wrote:
<blockquote cite="mid...@ie..." type="cite">
  <pre wrap="">Colin J. Williams wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Tim Hochberg wrote:
[snip]
  
    </pre>
    <blockquote type="cite">
      <pre wrap="">A style note: please use the named dtypes (int32, uint32, etc) rather 
than the old-style letter codes; the former is much clearer. The answer 
to your question might  have been immediately apparent had you been 
using named dtypes.

  
    
      </pre>
    </blockquote>
    <pre wrap="">+1
  
    </pre>
    <blockquote type="cite">
      <pre wrap=""> Personally, I'd also prefer people use the "ones([n])" syntax instead 
of the I-wish-it-were-deprecated-but-it's-too-much-to-hope-for "ones(n)" 
syntax.  T

-tim

  
    
      </pre>
    </blockquote>
    <pre wrap="">Could you elaborate please?

  
    </pre>
  </blockquote>
  <pre wrap=""><!---->Sure. The general form of the zeros function, and several others[1], is:

    zeros(shape, dtype)

 Here 'shape' is a sequence of one sort or another. There's also a 
second form that's applicable only to one dimensional arrays:

    zeros(length, dtype)

Where length is an integer. I don't recall if this is a historical 
legacy or is intended as a convenience function or a bit of both. Either 
way, the result is that there are two ways to spell "give me a 1D array 
of zeros with a given length and dtype":

    zeros([length], dtype)

and

    zeros(length, dtype)


I have two issues with having this second spelling. First, it's one more 
thing to remember. Whenever I see the scalar spelling I have to use a 
little bit extra of my limited brainpower to remember that it is not in 
fact a typo, but is instead a shortcut. The second issue is pedagogical. 
If people are initially exposed to the first form, the extension to 
multiple dimensions is straightforward. They'll probably guess the 
correct way right off the bat, and if not, they'll get it right away 
when it's explained. On the other hand, if they are initially exposed to 
the second form, the multidimensional form is far from obvious. In 
addition, they'll probably spend a long time thinking that the 
one-dimensional way is the normal way, but that we have to jump through 
weird hoops to get multidimensional arrays to work. That's bad 
propaganda for numpy. This all seems like a rather large price to pay to 
avoid typing the occasional pair of brackets.

That's my two cents. Just say not to form #2.

-tim



... [1] Yes, I'm neglecting the order parameter; I don't think it 
matters for this discussion.


  </pre>
</blockquote>
Tim,<br>
<br>
Many thanks.&nbsp; In general, there is sense in the Python dictum about
having one<br>
way to do things.&nbsp; Although, in this case [length] vs length for one
dimension doesn't<br>
exercise me greatly.&nbsp; I would be a bit more concerned about synonyms.<br>
<br>
Nobody has proposed using English yet - zeroes.<br>
<br>
Colin W.<br>
</body>
</html>

[Numpy-discussion] compile numpy on Mac

[Alan I. <ai...@am...>]

Experience of a brand new Mac user.
Barebones numpy install on Python 2.5 on a MacBook.

1. Where is my shell?

By default, bash is 'Terminal.app' in you applications folder.

2. Where is my editor?

You have many choices, but you can always start 'vim' from your bash shell.
Howevever, I just used the default configuration,
so no editor was needed. (Comment: I do not know if
this was a good decision, but I ended up with a working numpy.)

3. Where is my compiler?

The default OSX install does not include a compiler.
Go to http://developer.apple.com/tools/xcode and download the most 
recent Xcode.
(This is a very large download.)
Follow the easy installation directions in the accompanying 'readme' file.
(You must have administrative privileges.)

You will have to sign up for a free ADC account.

4. How to compile?

 From your bash shell, change to your build directory.
(I.e., wherever you unzipped your numpy tarball to.)
Do the usual:
python setup.py install
Compilation and installation takes a few minutes.
Then exit your shell.
You should be ready to go.

Re: [Numpy-discussion] problems installing NumPy on OSX

[Bob I. <bo...@re...>]

On 11/6/06, Christopher Barker <Chr...@no...> wrote:
>
> I think it's time to get MacPython2.5 and a set up packages on PythonMac
> org, and build a numpy for it (and SciPy and Matplotlib too...)
>
> Bob, can you set up the page, and then we can start populating it?

I'll put it up when there's something to put there. Doesn't make sense
to have an empty page.

-bob

Re: [Numpy-discussion] problems installing NumPy on OSX

[Christopher B. <Chr...@no...>]

ar...@st... wrote:
> I'm sorry, I was a tad too quick typing there. I meant to say "And do  
> I even need to [install Xcode] to run numpy?"

You need Xcode to build numpy (or anything else). If you can find a 
binary, then you should be able to just run that. One of us should get a 
binary for 2.5 out there soon.

by the way, if you can run 2.4 instead, you'll find a lot of binaries 
for various packages here:

http://www.pythonmac.org/packages/py24-fat/index.html

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] problems installing NumPy on OSX

[Christopher B. <Chr...@no...>]

I think it's time to get MacPython2.5 and a set up packages on PythonMac 
org, and build a numpy for it (and SciPy and Matplotlib too...)

Bob, can you set up the page, and then we can start populating it?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] problems installing NumPy on OSX

[Steve L. <lis...@ar...>]

> I'm sorry, I was a tad too quick typing there. I meant to say "And do
> I even need to [install Xcode] to run numpy?" Robert pointed out that
> a lot things mentioned in the install guide were necessary to run
> scipy, but that you could run numpy without them.
>
> Therefore I was wondering if installing the newest Xcode package was
> likely to fix the error message I am now getting when trying to
> install numpy:

I think Robert may have suggested to install the newest XCode because  
it will give you a newer gcc that can have a better chance compiling  
numpy correctly (or at least will remove another "unkown" to help  
find your true problem).

Maybe there'd be some "Universal Binary-aware"ness that the old xcode  
gcc might be missing that you'll get w/ the new one and since Python  
2.5 is universal, this might be it. Getting the new xcode would be  
the simplest part of the install anyway, so .. why not :-)

-steve

Re: [Numpy-discussion] problems installing NumPy on OSX

[<ar...@st...>]

Siterer Steve Lianoglou <lis...@ar...>:

> Hi,
>
>> And do I need even to run numpy (and not scipy)?
>
> I'm not sure what you mean with you last question here, but just in
> case it's not clear:
>
> If you want to use scipy, you need to install numpy.
> You do *not* have to install scipy if all you need is numpy.
>
> -steve

I'm sorry, I was a tad too quick typing there. I meant to say "And do  
I even need to [install Xcode] to run numpy?" Robert pointed out that  
a lot things mentioned in the install guide were necessary to run  
scipy, but that you could run numpy without them.

Therefore I was wondering if installing the newest Xcode package was  
likely to fix the error message I am now getting when trying to  
install numpy:

  File "numpy/core/setup.py", line 50, in generate_config_h
     raise "ERROR: Failed to test configuration"
ERROR: Failed to test configuration

    Arild

Re: [Numpy-discussion] problems installing NumPy on OSX

[Steve L. <lis...@ar...>]

Hi,

> And do I need even to run numpy (and not scipy)?

I'm not sure what you mean with you last question here, but just in  
case it's not clear:

If you want to use scipy, you need to install numpy.
You do *not* have to install scipy if all you need is numpy.

-steve

Re: [Numpy-discussion] problems installing NumPy on OSX

[Robert K. <rob...@gm...>]

ar...@st... wrote:
> Siterer Robert Kern <rob...@gm...>:
> 
>> ar...@st... wrote:
>>
>>> Python 2.5 is installed, and I have installed Apple's Developer's
>>> Tools (i.e. the package "December 2002 Mac OS X Developer Tools").
>> By the way, this is *really* old. Long before there were Universal binaries
>> (which is what Python 2.5 is). I believe you will want to install Xcode 2.4.1
>> which was released on Tuesday.
>>
>> --
>> Robert Kern
> 
> I was wondering about that, the instructions page on scipy.org wasn't  
> very specific. I don't need anything else than Xcode 2.4.1, so I can  
> remove the Dec2002 package? And do I need even to run numpy (and not  
> scipy)?

Yes, remove the Dec2002 package and install Xcode 2.4.1.

-- 
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
 an underlying truth."
  -- Umberto Eco

Re: [Numpy-discussion] problems installing NumPy on OSX

[<ar...@st...>]

Siterer Robert Kern <rob...@gm...>:

> ar...@st... wrote:
>
>> Python 2.5 is installed, and I have installed Apple's Developer's
>> Tools (i.e. the package "December 2002 Mac OS X Developer Tools").
>
> By the way, this is *really* old. Long before there were Universal binarie=
s
> (which is what Python 2.5 is). I believe you will want to install Xcode 2.=
4.1
> which was released on Tuesday.
>
> --
> Robert Kern

I was wondering about that, the instructions page on scipy.org wasn't =20
very specific. I don't need anything else than Xcode 2.4.1, so I can =20
remove the Dec2002 package? And do I need even to run numpy (and not =20
scipy)?

    Arild N=E6ss

Re: [Numpy-discussion] problems installing NumPy on OSX

[<ar...@st...>]

Siterer Robert Kern <rob...@gm...>:

> ar...@st... wrote:
>> gcc: _configtest.c
>> gcc: cannot specify -o with -c or -S and multiple compilations
>> gcc: cannot specify -o with -c or -S and multiple compilations
>> failure.
>
> You're using OS X 10.3.9? There is a bug in distutils on that  =20
> platform. It was
> fixed in Python's trunk, but I'm not sure where to find it.
>
> --
> Robert Kern

No, I'm on OS X 10.4.8, so my OS version shouldn't be the problem

    Arild N=E6ss

Re: [Numpy-discussion] problems installing NumPy on OSX

[Robert K. <rob...@gm...>]

ar...@st... wrote:

> Python 2.5 is installed, and I have installed Apple's Developer's  
> Tools (i.e. the package "December 2002 Mac OS X Developer Tools").

By the way, this is *really* old. Long before there were Universal binaries
(which is what Python 2.5 is). I believe you will want to install Xcode 2.4.1
which was released on Tuesday.

-- 
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
 an underlying truth."
  -- Umberto Eco

Re: [Numpy-discussion] problems installing NumPy on OSX

[Robert K. <rob...@gm...>]

ar...@st... wrote:
> gcc: _configtest.c
> gcc: cannot specify -o with -c or -S and multiple compilations
> gcc: cannot specify -o with -c or -S and multiple compilations
> failure.

You're using OS X 10.3.9? There is a bug in distutils on that platform. It was
fixed in Python's trunk, but I'm not sure where to find it.

-- 
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
 an underlying truth."
  -- Umberto Eco