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

RE: [Numpy-discussion] numpy.org redirection

[John A. T. <tu...@bl...>]

>>>>> "PFD" == Paul F Dubois <pa...@pf...>:

PFD> This is very generous of you.

by the way, it isn't such a big deal any more since the registrars have
opened up - I use http://www.directnic.com, which is only $15/year and has
nice easy admin of the domains - far superior to networksolutions

so I've done this for several open source projects (gnuplot, octave, and
latex2html) - usually when I use but haven't been able to contribute as
much in the way of development as I would have liked

-- 
John A. Turner, Ph.D.           Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY  10601
http://www.blueskystudios.com/             (914) 259-6319

RE: [Numpy-discussion] numpy.org redirection

[John A. T. <tu...@bl...>]

>>>>> "PFD" == Paul F Dubois <pa...@pf...>:

PFD> This is very generous of you. I don't want to own the domain. I'm not even
PFD> sure as a govt employee if you could give it to me. The new Python
PFD> Foundation, when it is up and running, would be appropriate. For now, I
PFD> suggest you just leave it as is.
PFD> I don't understand your remark about "real hosting". numpy.sourceforge.net
PFD> really is at sourceforge (? guess it is obvious I'm not familiar with this
PFD> term).

I just meant to have numpy.org hosted by sourceforge - but I'm not even
sure they do that

PFD> Both pages have pointers to each other. So technically it is a wash.
PFD> People looking for docs need to be on one, for releases on the other.
PFD> 
PFD> My guess is that the link on the project page back to the home page is a
PFD> little more confusing for a newbie than the clearly spelled-out link on the
PFD> home page to the project page. When I first used SF I thought "Home" would
PFD> be the project page. So my guess is that numpy.sourceforge.net would be
PFD> best. The operative word is "guess".

that's what I was thinking too - just thought I'd ask for other opinions

(I do think it's a little odd that the title of that page is still "LLNL
Python Extensions" rather than "Numerical Python")

ok, so the redirection is set up - will probably take a while to propogate,
of course

-JT

RE: [Numpy-discussion] numpy.org redirection

[Paul F. D. <pa...@pf...>]

This is very generous of you. I don't want to own the domain. I'm not even
sure as a govt employee if you could give it to me. The new Python
Foundation, when it is up and running, would be appropriate. For now, I
suggest you just leave it as is.
I don't understand your remark about "real hosting". numpy.sourceforge.net
really is at sourceforge (? guess it is obvious I'm not familiar with this
term).

Both pages have pointers to each other. So technically it is a wash.
People looking for docs need to be on one, for releases on the other.

My guess is that the link on the project page back to the home page is a
little more confusing for a newbie than the clearly spelled-out link on the
home page to the project page. When I first used SF I thought "Home" would
be the project page. So my guess is that numpy.sourceforge.net would be
best. The operative word is "guess".

-----Original Message-----
From: num...@li...
[mailto:num...@li...]On Behalf Of John
A. Turner
Sent: Tuesday, January 23, 2001 8:34 AM
To: Num...@li...
Subject: [Numpy-discussion] numpy.org redirection


some time ago I registered the domain numpy.org with the intention of
donating it to the group

just thought about it again today, and realized I could easily redirect it,
so my question is:

o does anyone object to my doing that?
o where should it point, here?

    http://numpy.sourceforge.net/

  or here?

    http://sourceforge.net/projects/numpy

if someone feels strongly that I should transfer ownership of the domain to
someone more central to development, etc., I'll be happy to do that -
otherwise I'm happy just redirecting and renewing it as it comes up, or at
some point setting up real hosting of the domain somewhere (sourceforge?)

--
John A. Turner, Ph.D.           Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY  10601
http://www.blueskystudios.com/             (914) 259-6319

_______________________________________________
Numpy-discussion mailing list
Num...@li...
http://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] numpy.org redirection

[John A. T. <tu...@bl...>]

some time ago I registered the domain numpy.org with the intention of
donating it to the group

just thought about it again today, and realized I could easily redirect it,
so my question is:

o does anyone object to my doing that?
o where should it point, here?

    http://numpy.sourceforge.net/

  or here?

    http://sourceforge.net/projects/numpy

if someone feels strongly that I should transfer ownership of the domain to
someone more central to development, etc., I'll be happy to do that -
otherwise I'm happy just redirecting and renewing it as it comes up, or at
some point setting up real hosting of the domain somewhere (sourceforge?)

-- 
John A. Turner, Ph.D.           Senior Research Associate
Blue Sky Studios, 44 S. Broadway, White Plains, NY  10601
http://www.blueskystudios.com/             (914) 259-6319

RE: [Numpy-discussion] Questions about organization (fwd)

[Paul F. D. <pa...@pf...>]

Just so you know: it is not ok for the official script to install RANLIB and
LALITE as a default part of the build. In fact, that used to be the case and
we changed it. There are people who have to change the way these packages
are built to use custom LAPACK and BLAS scripts. I won't be able to accept a
patch to NumPy that does this. NumPy's current clumsy structure is a result
of a decision not to break existing client scripts. These "Optional
Packages" are distributed with NumPy. The don't have to be, but again, there
were many people who thought it wasn't worth the confusion of having to go
get all of them separately. This arrangement appears to annoy distutils
purists, but distutils purity isn't the only consideration.

-----Original Message-----
From: num...@li...
[mailto:num...@li...]On Behalf Of Houman
G
Sent: Monday, January 22, 2001 10:19 AM
To: de...@Ac...
Cc: num...@li...
Subject: RE: [Numpy-discussion] Questions about organization (fwd)


On Sun, Jan 21, 2001 at 12:36:37PM -0800, Greg Stein wrote:
> FYI about what? I'm not sure that I see the point here.
>
> Are you trying to say that ActiveState can provide tools for packaging?
> Maybe that we can get NumPy packaged for people?

This one, I believe. HoumanG has been working on PyPM (like PPM for Python)
for which he is creating appropriate setup.py scripts for packages such as
NumPy.

I wrote a new setup.py script for NumPy a week ago. The script I wrote
builds the RANLIB and the LALITE as part of the core NumPy; and the binary
distribution of NumPy built with my script also installs the RANLIB and
LALITE.
If the question is that Distutils supports a source tree structure like the
one NumPy has, the question is no. However, I made a patch (for Distutils)
and submitted to SourceForge which allows the source tree to be spread in
more than one directory. A copy of the patch is in the attachment.


Houman

[Numpy-discussion] Ever hear of ROOT?

[Phlip <ppl...@om...>]

Nummies:

A colleague recently asked me to look up something called "ROOT". I 
complained "I can't e-search for  'root'! I'd get a million false hits!"

ROOT's here:

	http://root.cern.ch

It's a high-end version of programs like GnuPlot or  OpenDx; it's written 
for  physicists at CERN, and it can handle terabyte databases.

The bad news it bonds to a questionable "C++ Interpreter" for its 
scripting end. We all know that interpreting a language designed to be 
compiled represents the worst of both worlds.

Has anyone plugged their  NumericPython into ROOT? How hard could that be?

-- 
  Phlip                          phl...@my...
============ http://c2.com/cgi/wiki?PhlIp ============
  --  http://users.deltanet.com/~tegan/home.html  --

RE: [Numpy-discussion] Questions about organization (fwd)

[Houman G <Ho...@Ac...>]

On Sun, Jan 21, 2001 at 12:36:37PM -0800, Greg Stein wrote:
> FYI about what? I'm not sure that I see the point here.
>
> Are you trying to say that ActiveState can provide tools for packaging?
> Maybe that we can get NumPy packaged for people?

This one, I believe. HoumanG has been working on PyPM (like PPM for Python)
for which he is creating appropriate setup.py scripts for packages such as
NumPy.

I wrote a new setup.py script for NumPy a week ago. The script I wrote
builds the RANLIB and the LALITE as part of the core NumPy; and the binary
distribution of NumPy built with my script also installs the RANLIB and
LALITE.
If the question is that Distutils supports a source tree structure like the
one NumPy has, the question is no. However, I made a patch (for Distutils)
and submitted to SourceForge which allows the source tree to be spread in
more than one directory. A copy of the patch is in the attachment.


Houman

[Numpy-discussion] Debug version of numpy for Win32

[<Edw...@da...>]

Has anyone built a debug version of _numpy.pyd (_numpy_d.pyd) for Windows
NT (MS Visual Studio C++ 6.0)?

RE: [Numpy-discussion] Questions about organization

[Tony S. <ant...@ie...>]

On Sun, 21 Jan 2001, Paul F. Dubois wrote:

> You wrote:
> 
> ...As I understand it the goals are
> 
> 1) keep all of the current packages in the distribution
> 2) the following imports will work individually or together:
>    a) import Numeric
>    b) import FFT
>    c) import LinearAlgebra
>    d) import MLab
>    e) import Matrix
>    f) import Precision
>    g) import RandomArray
>    h) import UserArray
>    i) import ranlib
>    j) import umath
>    k) import RNG
>    l) import MA
> 3) minimal changes in the source
> 
> I just need some direction so that I can get things working.  I think that
> the simplest thing is to merge the RANLIB and LALITE packages with the core
> of Numeric and make the building and installation of them an option.  This
> fits beter with the paradigm of distutils.
> 
> ---
> You are describing exactly what we used to have. We changed it. We had
> reasons that haven't disappeared.
> 
> (1) is not necessarily a goal. We had a long argument about that, too. If
> anything, (1) is an anti-goal.
>     Under no circumstances am I willing to move packages back to the core. I
> think it more likely that
>     all the optional packages will go somewhere else entirely. We need a
> more organized structure.
>     For historical reasons people did not want to change the way some of the
> above are NOT packages.

OK, I guess I mis-rememberd the conclusion.  If we have a more organized
structure than I think that most of the problems would be solved.  Whether
RANLIB and LALITE are sub-packages of Numeric, or they are installed
parallel to Numeric the setup.py scripts would be simple.  If they are
parallel to Numeric than they can be imported like they are now if that is a
concern.

> (2) No, it is not possible to import those modules independently. Some
> depend on the others.

All of the import lines that I gave work with the Numeric that I have
installed: I left out the ones that didn't.  Let me know which ones should be
able to be imported and if there are any missing.

> (3) is not a goal, but it is not permissible to require changes in CLIENT
> code, such as changing where the include files get installed.

By client code do you mean non-python code using the libraries?

> (4) Goal: enable people to easily modify LinearAlgebra so that a
> user-specified BLAS and/or LAPACK library is used.

I've been playing with this and on *nix types systems it shouldn't be too
hard to do as options to setup.py.  I don't know how BLAS and LAPAK get
installed on non *nix systems.  My plan has been to do minimal autoconf type
scanning (taking into consideration command line options) to look for
existing libraries.

> (5) Goal: not make it harder to make distributions on the Mac or Windows
> just to make RPMs easier.
> 

I'm trying to go through distutils when the required functionality is
already present so it shouldn't be mch of an issue.  I do have a W2k laptop
that I can test things on in extremis.

The main roadblock is trying to figure out what to do with RANLIB and LALITE.

Tony

RE: [Numpy-discussion] Questions about organization

[Paul F. D. <pa...@pf...>]

You wrote:

...As I understand it the goals are

1) keep all of the current packages in the distribution
2) the following imports will work individually or together:
   a) import Numeric
   b) import FFT
   c) import LinearAlgebra
   d) import MLab
   e) import Matrix
   f) import Precision
   g) import RandomArray
   h) import UserArray
   i) import ranlib
   j) import umath
   k) import RNG
   l) import MA
3) minimal changes in the source

I just need some direction so that I can get things working.  I think that
the simplest thing is to merge the RANLIB and LALITE packages with the core
of Numeric and make the building and installation of them an option.  This
fits beter with the paradigm of distutils.

---
You are describing exactly what we used to have. We changed it. We had
reasons that haven't disappeared.

(1) is not necessarily a goal. We had a long argument about that, too. If
anything, (1) is an anti-goal.
    Under no circumstances am I willing to move packages back to the core. I
think it more likely that
    all the optional packages will go somewhere else entirely. We need a
more organized structure.
    For historical reasons people did not want to change the way some of the
above are NOT packages.
(2) No, it is not possible to import those modules independently. Some
depend on the others.
(3) is not a goal, but it is not permissible to require changes in CLIENT
code, such as changing where the include files get installed.
(4) Goal: enable people to easily modify LinearAlgebra so that a
user-specified BLAS and/or LAPACK library is used.
(5) Goal: not make it harder to make distributions on the Mac or Windows
just to make RPMs easier.

Re: [Numpy-discussion] Questions about organization

[John J. L. <ph...@cs...>]

On Sun, 21 Jan 2001, Tony Seward wrote:

> On Sun, 21 Jan 2001, John J. Lee wrote:
[...]
> I'm not sure what you mean.  Even './setup_all.py build' doen't work for
> FFT, LALITE, RANLIB and RNG.
>
> Right now one has to have already installed the headers from the core of
> Numeric in order to even build these modules.  The sequence is thus
>
> 1) get source
> 2) install the core
> 3) build or install the submodules

Ah, sorry, I didn't read you post properly.  I thought you were just
having trouble compiling something you didn't really need, and wanted to
avoid compiling it.

You may already know this, but this has been discussed on the
distutils-sig mailing list (and maybe this one too) just recently.  I
don't recall what conclusions they came to, if any - things are held up at
the moment because Greg Ward just moved house and is effectively off-line.
I guess when he appears again he'll be swamped, so don't hold your breath
for changes in distutils itself.


John

Re: [Numpy-discussion] Questions about organization

[Tony S. <ant...@ie...>]

On Sun, 21 Jan 2001, John J. Lee wrote:

> On Sat, 20 Jan 2001, Tony Seward wrote:
> 
> > I've been trying to get the setup.py scripts in the Numeric distribution to
> > build binary distributions.  I have tried several things but what always
> > ends up being a problem is the current Numeric organization, specifically
> > LALITE and RANLIB.  They just don't fit well with the distutils paradigm.
> >
> > If they were packaged as part of the Numeric core but were a build-time
> > option, I think that I could get things to work much more easily.  The
> [...]
> 
> Can't you just edit the list of extensions in setup_all.py?
> 
> Or has that changed?
> 
> 
> John
> 

I'm not sure what you mean.  Even './setup_all.py build' doen't work for
FFT, LALITE, RANLIB and RNG.

Right now one has to have already installed the headers from the core of
Numeric in order to even build these modules.  The sequence is thus

1) get source
2) install the core
3) build or install the submodules

As is stands, even if the Numeric core is already installed, it is not
possible to make a binary distribution of the LALITE package (and maybe
others).  This could be fixed easily of the LALITE package, but I havn't
looked to see if there are other problems with the other packages.  The
purpose of distutils is that the sequence for a given distribution is

1) get the source
2) build, or install, or build a binary distribution and you're done

This can't be done with the way that things are organized right now.  There
are probably several ways to deal with this, but first a decision needs to
be made as to what the goals are.  As I understand it the goals are

1) keep all of the current packages in the distribution
2) the following imports will work individually or together:
   a) import Numeric
   b) import FFT
   c) import LinearAlgebra
   d) import MLab
   e) import Matrix
   f) import Precision
   g) import RandomArray
   h) import UserArray
   i) import ranlib
   j) import umath
   k) import RNG
   l) import MA
3) minimal changes in the source

I just need some direction so that I can get things working.  I think that
the simplest thing is to merge the RANLIB and LALITE packages with the core
of Numeric and make the building and installation of them an option.  This
fits beter with the paradigm of distutils.

Tony

Re: [Numpy-discussion] Questions about organization

[John J. L. <ph...@cs...>]

On Sat, 20 Jan 2001, Tony Seward wrote:

> I've been trying to get the setup.py scripts in the Numeric distribution to
> build binary distributions.  I have tried several things but what always
> ends up being a problem is the current Numeric organization, specifically
> LALITE and RANLIB.  They just don't fit well with the distutils paradigm.
>
> If they were packaged as part of the Numeric core but were a build-time
> option, I think that I could get things to work much more easily.  The
[...]

Can't you just edit the list of extensions in setup_all.py?

Or has that changed?


John

[Numpy-discussion] Questions about organization

[Tony S. <ant...@ie...>]

I've been trying to get the setup.py scripts in the Numeric distribution to
build binary distributions.  I have tried several things but what always
ends up being a problem is the current Numeric organization, specifically
LALITE and RANLIB.  They just don't fit well with the distutils paradigm.

If they were packaged as part of the Numeric core but were a build-time
option, I think that I could get things to work much more easily.  The
configuration part of distutils is still a bit imature but overcomming that
would just require a slightly more involved setup.py.

I don't want to go ahead if there is no chance of it being accepted.

Tony

[Numpy-discussion] calling numpy from C++

[<Edw...@da...>]

I've got Python 20 and numerical python installed and running, i.e., I can
run python scripts and call import module Numerical and use arrays,etc.

I've also been successful at calling python scripts from C/C++ code (MSVC++
6.0) - Py_Initialize(), Py_BuildValue() etc. and building the de-bug
version of python20.dll (python20_d.dll) so I can debug-step through the
code.

However, I can't seem to be able to call numpy functions from C/C++ -
PyArray_FromDims(), etc.  My code will compile and link but, at runtime, I
get an exception error.

It seems that either I need to create a numpy.dll that will live in
winnt/system32 or somehow need to modify python20.dll to include the numpy
functions.

How do I do that?

Thanks.

Re: [Numpy-discussion] multipack

[Jim B. <bo...@ll...>]

Thanks to Arne and Paul I took the time to find out what was going 
on. It turns out that the CVS has multipack 0.8 and Travis added the 
cephes, numpyio and sigtools modules to multipack in going from 0.7 
to 0.8. I did the usual things to account for a non-standard python 
location at the topmost level of Multipack as I had before with 0.7 
but should have also tweaked the Makefiles in the cephes, numpyio and 
sigtools directories. The result was that these modules were built 
with Python 1.5 and all the others with 2.0 and I confused myself as 
to where the problem was.

But when I tried to build the cephes module using Python 2.0 I got 
the following error:
gcc -O2 -I/usr/local/include/python2.0    -c -o amos_wrappers.o amos_wrappers.c
In file included from cephes/mconf.h:162,
                  from amos_wrappers.h:12,
                  from amos_wrappers.c:8:
cephes/protos.h:67: parse error before `sizeof'
cephes/protos.h:68: parse error before `sizeof'
cephes/protos.h:69: parse error before `sizeof'
make: *** [amos_wrappers.o] Error 1

the line:
gcc -O2 -I/usr/local/include/python1.5 -c -o amos_wrappers.o amos_wrappers.c

works fine. I have tried this on another machine with Python 2.0 and 
got the same
error. The Python.h includes changed quite a bit in going from 1.5 to 2.0.
Any ideas as to what is wrong would be welcome.
  Has anyone installed multipack 0.8 using Python 2.0?


Jim

>I install the multipack-0.7 with my new installation of Python2.0 and I
>don't have any
>warning :
>maybe a problem with PYTHONPATH if your old Multipack under your old
>Pyhon1.5 is still present?
>
>
>Jim Boyle wrote:
>>
>>  I pulled the multipack code from the CVS server and built it for my
>>  new installation of Python 2.0.
>>  When I import Multipack I get:
>>
>>  WARNING: Python C API version mismatch for module cephes:
>>    This Python has API version 1009, module cephes has version 1007
>>
>>  this warning occurs for the numpyio and sigtools modules.
>>
>>  Have I done something screwy in the installation, or do the modules
>>  have to be updated?
>>  If the latter is there any guidance on what to fix? What are the
>>  routines/procedures that changed in going from version 1007 to 1009?
>>
>>  So far everything appears to provide the correct answers, so the API
>>  mismatch is not crippling. However, from past experience I know that
>  > ignoring warnings often ends in tears.
>>

RE: [Numpy-discussion] multipack

[Paul F. D. <pa...@pf...>]

This would typically mean that you are importing the package into a
different python than the one you used to build it.

-----Original Message-----
From: num...@li...
[mailto:num...@li...]On Behalf Of Jim
Boyle
Sent: Thursday, January 18, 2001 12:03 PM
To: num...@li...
Subject: Re: [Numpy-discussion] multipack


I pulled the multipack code from the CVS server and built it for my
new installation of Python 2.0.
When I import Multipack I get:

WARNING: Python C API version mismatch for module cephes:
  This Python has API version 1009, module cephes has version 1007

this warning occurs for the numpyio and sigtools modules.

Have I done something screwy in the installation, or do the modules
have to be updated?
If the latter is there any guidance on what to fix? What are the
routines/procedures that changed in going from version 1007 to 1009?

So far everything appears to provide the correct answers, so the API
mismatch is not crippling. However, from past experience I know that
ignoring warnings often ends in tears.

Jim

>These pages are depreciated, as Travis has moved. I could not find the
>announcement for the new pages. Menawhile you can check out these
>packages from the public cvs server of Pearu Peterson.
>
>For an overview of the cvs content look at
>
>http://cens.ioc.ee/cgi-bin/cvsweb/python/multipack/
>
>and for instructions to get it out of cvs look at
>
>http://cens.ioc.ee/projects/pysymbolic/
>
>HTH,
>__Janko
>
>
>John J. Lee writes:
>  > On Tue, 16 Jan 2001, Arne Keller wrote:
>  >
>  > > I'm looking for the Multipack and cephes python modules by Travis
>  > > Oliphant.
>  > >
>  > > The Multipack Home page link on numpy.sourceforge gives a 404...
>  >
>  > http://oliphant.netpedia.net/
>  >
>  > http://oliphant.netpedia.net/multipack.html
>  >
>  > BTW, I've partly written a distutils script for this with the intention
of
>  > making it easier to compile on windows (the setup.py works on linux but
I
>  > need to change some things to make it set up the setup script according
to
>  > the way the source has been set up).
>  >
>  > It seems distutils doesn't have explicit support for FORTRAN, so
something
>  > needs changing there for it to work cross-platform.  I haven't got any
>  > feedback yet from the Distutils people on how best to do this, but if
>  > anyone reading this who is practiced at compiling FORTRAN and C
>  > (especially on windows compilers) and wouldn't mind adding the little
bits
>  > required to support FORTRAN for their system once this has been
decided,
>  > mail me.


_______________________________________________
Numpy-discussion mailing list
Num...@li...
http://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] multipack

[arne k. <ar...@cy...>]

I install the multipack-0.7 with my new installation of Python2.0 and I
don't have any
warning :
maybe a problem with PYTHONPATH if your old Multipack under your old
Pyhon1.5 is still present? 


Jim Boyle wrote:
> 
> I pulled the multipack code from the CVS server and built it for my
> new installation of Python 2.0.
> When I import Multipack I get:
> 
> WARNING: Python C API version mismatch for module cephes:
>   This Python has API version 1009, module cephes has version 1007
> 
> this warning occurs for the numpyio and sigtools modules.
> 
> Have I done something screwy in the installation, or do the modules
> have to be updated?
> If the latter is there any guidance on what to fix? What are the
> routines/procedures that changed in going from version 1007 to 1009?
> 
> So far everything appears to provide the correct answers, so the API
> mismatch is not crippling. However, from past experience I know that
> ignoring warnings often ends in tears.
> 
> Jim
> 
> >These pages are depreciated, as Travis has moved. I could not find the
> >announcement for the new pages. Menawhile you can check out these
> >packages from the public cvs server of Pearu Peterson.
> >
> >For an overview of the cvs content look at
> >
> >http://cens.ioc.ee/cgi-bin/cvsweb/python/multipack/
> >
> >and for instructions to get it out of cvs look at
> >
> >http://cens.ioc.ee/projects/pysymbolic/
> >
> >HTH,
> >__Janko
> >
> >
> >John J. Lee writes:
> >  > On Tue, 16 Jan 2001, Arne Keller wrote:
> >  >
> >  > > I'm looking for the Multipack and cephes python modules by Travis
> >  > > Oliphant.
> >  > >
> >  > > The Multipack Home page link on numpy.sourceforge gives a 404...
> >  >
> >  > http://oliphant.netpedia.net/
> >  >
> >  > http://oliphant.netpedia.net/multipack.html
> >  >
> >  > BTW, I've partly written a distutils script for this with the intention of
> >  > making it easier to compile on windows (the setup.py works on linux but I
> >  > need to change some things to make it set up the setup script according to
> >  > the way the source has been set up).
> >  >
> >  > It seems distutils doesn't have explicit support for FORTRAN, so something
> >  > needs changing there for it to work cross-platform.  I haven't got any
> >  > feedback yet from the Distutils people on how best to do this, but if
> >  > anyone reading this who is practiced at compiling FORTRAN and C
> >  > (especially on windows compilers) and wouldn't mind adding the little bits
> >  > required to support FORTRAN for their system once this has been decided,
> >  > mail me.
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
Arne Keller
Laboratoire de Photophysique Moleculaire du CNRS, Bat. 213.
Universite de Paris-Sud, 91405 Orsay Cedex, France.
tel.: (33) 1 69 15 82 83 -- fax. : (33) 1 69 15 67 77

Re: [Numpy-discussion] multipack

[Jim B. <bo...@ll...>]

I pulled the multipack code from the CVS server and built it for my 
new installation of Python 2.0.
When I import Multipack I get:

WARNING: Python C API version mismatch for module cephes:
  This Python has API version 1009, module cephes has version 1007

this warning occurs for the numpyio and sigtools modules.

Have I done something screwy in the installation, or do the modules 
have to be updated?
If the latter is there any guidance on what to fix? What are the 
routines/procedures that changed in going from version 1007 to 1009?

So far everything appears to provide the correct answers, so the API 
mismatch is not crippling. However, from past experience I know that 
ignoring warnings often ends in tears.

Jim

>These pages are depreciated, as Travis has moved. I could not find the
>announcement for the new pages. Menawhile you can check out these
>packages from the public cvs server of Pearu Peterson.
>
>For an overview of the cvs content look at
>
>http://cens.ioc.ee/cgi-bin/cvsweb/python/multipack/
>
>and for instructions to get it out of cvs look at
>
>http://cens.ioc.ee/projects/pysymbolic/
>
>HTH,
>__Janko
>
>
>John J. Lee writes:
>  > On Tue, 16 Jan 2001, Arne Keller wrote:
>  >
>  > > I'm looking for the Multipack and cephes python modules by Travis
>  > > Oliphant.
>  > >
>  > > The Multipack Home page link on numpy.sourceforge gives a 404...
>  >
>  > http://oliphant.netpedia.net/
>  >
>  > http://oliphant.netpedia.net/multipack.html
>  >
>  > BTW, I've partly written a distutils script for this with the intention of
>  > making it easier to compile on windows (the setup.py works on linux but I
>  > need to change some things to make it set up the setup script according to
>  > the way the source has been set up).
>  >
>  > It seems distutils doesn't have explicit support for FORTRAN, so something
>  > needs changing there for it to work cross-platform.  I haven't got any
>  > feedback yet from the Distutils people on how best to do this, but if
>  > anyone reading this who is practiced at compiling FORTRAN and C
>  > (especially on windows compilers) and wouldn't mind adding the little bits
>  > required to support FORTRAN for their system once this has been decided,
>  > mail me.

Re: [Numpy-discussion] multipack

[arne k. <ar...@cy...>]

"John J. Lee" wrote:
> 
> On Tue, 16 Jan 2001, Arne Keller wrote:
> 
> > I'm looking for the Multipack and cephes python modules by Travis
> > Oliphant.
> >
> > The Multipack Home page link on numpy.sourceforge gives a 404...
> 
> http://oliphant.netpedia.net/
> 
> http://oliphant.netpedia.net/multipack.html

did you try these links?

For me it returns the following message:

Not Found

The requested URL / was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use
an ErrorDocument to 

> 
> BTW, I've partly written a distutils script for this with the intention of
> making it easier to compile on windows (the setup.py works on linux but I
> need to change some things to make it set up the setup script according to
> the way the source has been set up).
> 
> It seems distutils doesn't have explicit support for FORTRAN, so something
> needs changing there for it to work cross-platform.  I haven't got any
> feedback yet from the Distutils people on how best to do this, but if
> anyone reading this who is practiced at compiling FORTRAN and C
> (especially on windows compilers) and wouldn't mind adding the little bits
> required to support FORTRAN for their system once this has been decided,
> mail me.
> 
> John
> 
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> http://lists.sourceforge.net/lists/listinfo/numpy-discussion

-- 
Arne Keller
Laboratoire de Photophysique Moleculaire du CNRS, Bat. 213.
Universite de Paris-Sud, 91405 Orsay Cedex, France.
tel.: (33) 1 69 15 82 83 -- fax. : (33) 1 69 15 67 77

Re: [Numpy-discussion] multipack

[Janko H. <jh...@if...>]

These pages are depreciated, as Travis has moved. I could not find the
announcement for the new pages. Menawhile you can check out these
packages from the public cvs server of Pearu Peterson.

For an overview of the cvs content look at

http://cens.ioc.ee/cgi-bin/cvsweb/python/multipack/

and for instructions to get it out of cvs look at

http://cens.ioc.ee/projects/pysymbolic/

HTH,
__Janko


John J. Lee writes:
 > On Tue, 16 Jan 2001, Arne Keller wrote:
 > 
 > > I'm looking for the Multipack and cephes python modules by Travis
 > > Oliphant.
 > >
 > > The Multipack Home page link on numpy.sourceforge gives a 404...
 > 
 > http://oliphant.netpedia.net/
 > 
 > http://oliphant.netpedia.net/multipack.html
 > 
 > BTW, I've partly written a distutils script for this with the intention of
 > making it easier to compile on windows (the setup.py works on linux but I
 > need to change some things to make it set up the setup script according to
 > the way the source has been set up).
 > 
 > It seems distutils doesn't have explicit support for FORTRAN, so something
 > needs changing there for it to work cross-platform.  I haven't got any
 > feedback yet from the Distutils people on how best to do this, but if
 > anyone reading this who is practiced at compiling FORTRAN and C
 > (especially on windows compilers) and wouldn't mind adding the little bits
 > required to support FORTRAN for their system once this has been decided,
 > mail me.
 > 
 > 
 > John
 > 
 > 
 > _______________________________________________
 > Numpy-discussion mailing list
 > Num...@li...
 > http://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] strange underflows

[Jean-Bernard A. <jb...@ph...>]

Hey Numpy people!

I just compiled the last NumPy. Underflows don't give zero but generate
OverflowError: 

Python 2.0 (#2, Dec 15 2000, 15:04:31) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more information.
Hello from .pythonrc.py
>>> import Numeric
>>> Numeric.__version__
'17.2.0'
>>> Numeric.exp(-1.42676746e+12)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: math range error
>>> 

How to suppress these? Any hint?


Jean-Bernard

Re: [Numpy-discussion] multipack

[John J. L. <ph...@cs...>]

On Tue, 16 Jan 2001, Arne Keller wrote:

> I'm looking for the Multipack and cephes python modules by Travis
> Oliphant.
>
> The Multipack Home page link on numpy.sourceforge gives a 404...

http://oliphant.netpedia.net/

http://oliphant.netpedia.net/multipack.html

BTW, I've partly written a distutils script for this with the intention of
making it easier to compile on windows (the setup.py works on linux but I
need to change some things to make it set up the setup script according to
the way the source has been set up).

It seems distutils doesn't have explicit support for FORTRAN, so something
needs changing there for it to work cross-platform.  I haven't got any
feedback yet from the Distutils people on how best to do this, but if
anyone reading this who is practiced at compiling FORTRAN and C
(especially on windows compilers) and wouldn't mind adding the little bits
required to support FORTRAN for their system once this has been decided,
mail me.


John

[Numpy-discussion] multipack

[Arne K. <arn...@pp...>]

I'm looking for the Multipack and cephes python modules by Travis
Oliphant.

The Multipack Home page link on numpy.sourceforge gives a 404...


-- 
Arne Keller
Laboratoire de Photophysique Moleculaire du CNRS, Bat. 213.
Universite de Paris-Sud, 91405 Orsay Cedex, France.
tel.: (33) 1 69 15 82 83 -- fax. : (33) 1 69 15 67 77

[Numpy-discussion] Another CXX question

[<pf...@mm...>]

This is probably a stupid coding error, but the following code generates
the error:

C:\Program Files\Microsoft Visual
Studio\MyProjects\Xrawdatafile\Xrawdatafile.cpp(32) : error C2065:
'FromAPI' : undeclared identifier

I've marked the line in the listing that causes the error.  It occurs in
the function that creates a new datafile_type object to return to the
interpreter.   Right now the datafile_type object is very simple, and has
but one method that prints a hardcoded string.  I'm using CXX-4.?? with
Visual C++ 6.0 and SP3.  I'm going to download SP4 tonight and see if that
helps, but any hints would be appreciated.  I haven't been doing C++ for
very long, so I'm probably mising something obvious.

//****************************************************************************************************************
// Xrawdatafile.cpp : Defines the entry point for the DLL application.
//

#include "stdafx.h"
#include <CXX/CXX_Objects.h>
#include <CXX/CXX_Extensions.h>
#include "Xrawdatafile.h"
#include "datafile_type.h"

BOOL APIENTRY DllMain(HANDLE hModule, DWORD  ul_reason_for_call, LPVOID
lpReserved) {
     switch (ul_reason_for_call) {
          case DLL_PROCESS_ATTACH:
          case DLL_THREAD_ATTACH:
          case DLL_THREAD_DETACH:
          case DLL_PROCESS_DETACH:
               break;
    }
    return TRUE;
}

class datafile_module : Py::ExtensionModule<datafile_module> {
public:
     datafile_module() : Py::ExtensionModule<datafile_module>("datafile") {
          datafile_type::init();
          add_varargs_method("datafile",
&datafile_module::new_datafile,"datafile(filename)");
          initialize("interface to ThermoFinnigan XRaw data files.");
     }
     virtual ~datafile_module() {
     };
private:
     Py::Object new_datafile(const Py::Tuple& args) {
          return Py::asObject((new datafile_type()));   //  THIS LINE
CAUSES THE ERROR
     }
};


extern "C" __declspec(dllexport)  void initdatafile(void) {
     static datafile_module *dfm = new datafile_module;
}

//****************************************************************************************************************************