matplotlib-devel Mailing List for matplotlib

>>>>> "Tom" == Tom Loredo <lo...@as...> writes:
 Tom> updating scipy_core. So I suspect either you'll have to find
 Tom> a more clever way of importing ffts that maintains
 Tom> compatibility across recent inconsistent scipy_core releases,
 Tom> or you'll have to require mpl users to update scipy_core. A
 Tom> bit of a mess....
I don't see that as a problem -- people who want to use scipy core
should expect to have to update often for the next while, since it is
a new package.
JDH

John Hunter wrote:
> I know there has been some recent discussion and work on the scipy dev
> list about a new package loading scheme, but am not sure what the
> current status is (still in flux, finished). Robert or Travis, please
> advise about the status of this module, and when you expect a scipy
> release which has the new package loading scheme out.
I think we'll be going through one more iteration, but I won't be able to attend
to it until Jan 3. If we follow my plan, then you would do
 from scipy.corefft import *
No weird import tricks are involved.
-- 
Robert Kern
rob...@gm...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

> In [4]: import scipy.fftpack
> ------------------------------------------------------------
> Traceback (most recent call last):
> File "<console>", line 1, in ?
> ImportError: No module named fftpack
> 
> Although scipy.fftpack is defined in 0.8.4, you can't import from it
> like a normal module.
Yes, this has been the subject of attention in the last week
(see e.g. the scipy-dev threads on the location of the random
module, and on "fftpack issues"). They decided to abandon
some of the delayed import magic, and the current SVN checkout
reflects this. You can now import fftpack as before. I 
suspect there will be a new release soon after the holiday
reflecting this fix. Even after such a release, there will
be a problem with folks updating mpl without also updating
scipy_core. So I suspect either you'll have to find a more
clever way of importing ffts that maintains compatibility
across recent inconsistent scipy_core releases, or you'll
have to require mpl users to update scipy_core. A bit of
a mess....
-Tom

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 >> For others trying to use things as they are now, the following
 >> quick fix gets most things to work: Just change __init__.py in
 >> site-packages/matplotlib/numerix/fft from: elif which[0] ==
 >> "scipy": from scipy.basic.fft import * to: elif which[0] ==
 >> "scipy": # from scipy.basic.fft import * from
 >> scipy.basic.fftpack import *
 >> 
 Eric> John,
 Eric> It looks like this could be handled in CVS mpl with:
 Eric> elif which[0] == "scipy": from scipy.fftpack import *
 Eric> scipy itself imports basic.fft (released version) or
 Eric> basic.fftpack (SVN) as fftpack, so there is no need to go to
 Eric> scipy.basic. Correct?
 Eric> I haven't tested it yet, though. If no one gets to it
 Eric> sooner, I may be able to take a closer look this evening.
I don't think this works with the latest release
In [2]: import scipy
In [3]: scipy.__core_version__
Out[3]: '0.8.4'
In [4]: import scipy.fftpack
------------------------------------------------------------
Traceback (most recent call last):
 File "<console>", line 1, in ?
ImportError: No module named fftpack
Although scipy.fftpack is defined in 0.8.4, you can't import from it
like a normal module.
JDH

> 
> For others trying to use things as they are now, the following quick
> fix gets most things to work: Just change __init__.py in 
> site-packages/matplotlib/numerix/fft from:
> 
> elif which[0] == "scipy":
> from scipy.basic.fft import *
> to: 
> 
> elif which[0] == "scipy":
> # from scipy.basic.fft import *
> from scipy.basic.fftpack import *
> 
John,
It looks like this could be handled in CVS mpl with:
elif which[0] == "scipy":
 from scipy.fftpack import *
scipy itself imports basic.fft (released version) or basic.fftpack (SVN) 
as fftpack, so there is no need to go to scipy.basic. Correct?
I haven't tested it yet, though. If no one gets to it sooner, I may be 
able to take a closer look this evening.
Eric

John,
Thanks for the clarification---and for responding so close to
the holiday!
> It seems like matplotlib should track released scipy rather than scipy
> svn, but I can see arguments for both sides (matplotlib cvs perhaps
> should track scipy svn, but then we can't do a release until scipy
> does...).
I understand the issue, and it does seem to me you should track
the release.
> I know there has been some recent discussion and work on the scipy dev
> list about a new package loading scheme, but am not sure what the
> current status is (still in flux, finished).
At least part of it was given up on, and I believe Pearu and Travis
checked in those changes a few days ago. It does sound like it's
time for a new release, provided the scheme has settled.
For others trying to use things as they are now, the following quick
fix gets most things to work: Just change __init__.py in 
site-packages/matplotlib/numerix/fft from:
elif which[0] == "scipy":
 from scipy.basic.fft import *
to: 
elif which[0] == "scipy":
 # from scipy.basic.fft import *
 from scipy.basic.fftpack import *
Do it in site-packages and not in the distribution, so your
distribution stays in sync with its CVS version. (I'm not
sure if this matters.)
I don't know if this does all that is required for pylab's fft
stuff (I only use it for plotting), but it does get *most*
examples to plot (I tried a random assortment of them).
However, a few examples do have problems, some trivial, others
perhaps not so. Some examples:
% pythonw specgram_demo.py 
Traceback (most recent call last):
 File "specgram_demo.py", line 24, in ?
 Pxx, freqs, bins, im = specgram(x, NFFT=NFFT, Fs=Fs, noverlap=900)
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line 
2206, in specgram
 ret = gca().specgram(*args, **kwargs)
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 3379, 
in specgram
 window, noverlap)
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/mlab.py", line 1120, 
in specgram
 if x.typecode()==Complex: numFreqs = NFFT
AttributeError: 'scipy.ndarray' object has no attribute 'typecode' 
scipy_core has changed how typecodes are handled so I suspect this
is an inconsistency that will survive revisions. I don't know what
else in mpl it may affect.
% pythonw boxplot_demo.py 
Traceback (most recent call last):
 File "boxplot_demo.py", line 17, in ?
 boxplot(data)
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line 
1745, in boxplot
 ret = gca().boxplot(*args, **kwargs)
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 1061, 
in boxplot
 widths = distance * min(0.15, 0.5/distance)
ZeroDivisionError: float division
I don't know what's behind this.
% pythonw anim.py
The animated plot appears to work fine---what I could see of it!
Its window can't be brought to the front, and won't respond to
clicks on the close button. I believe this has always happened
and is unrelated to scipy; it's an OS X GUI issue (I'm using TkAgg).
%pythonw dannys_example.py
This failed for me because it is written to explicitly
use Numeric. A simple change at the top to 
"import matplotlib.numerix as Numeric" has it plot fine with scipy.
Someone should check it with numarray and if it survives, make
the change.
Many other examples worked just fine, with images, contour plots,
histograms, TeX labels, axis tricks, interactivity, etc.. So perhaps 
the only scipy_core changes that are significant for mpl are the fft
module move and the typecode change.
-Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

>>>>> "Tom" == Tom Loredo <lo...@as...> writes:
 Tom> Hi folks,
 Tom> I just installed the latest svn/cvs scipy_core, scipy, and
 Tom> mpl on OS 10.3.9, Py 2.4.1. There has been some shuffling
 Tom> around of packages and package names in scipy in the last
 Tom> week or two, and finally core+scipy is working without import
 Tom> complaints (though 10 of the fftpack tests fail). However,
 Tom> now NOTHING requiring pylab works---every attempt to import
 Tom> pylab eventually fails with something like:
 Tom> File
 Tom> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/
 Tom> __init__.py", line 143, in ? __import__('fft', g, l) File
 Tom> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/fft/
 Tom> __init__.py", line 8, in ? from scipy.basic.fft import *
 Tom> ImportError: No module named fft
That is a bit of a problem, since this is correct with the last
released version of scipy
In [1]: import scipy
In [2]: scipy.__core_version__
Out[2]: '0.8.4'
In [3]: from scipy.basic.fft import *
It seems like matplotlib should track released scipy rather than scipy
svn, but I can see arguments for both sides (matplotlib cvs perhaps
should track scipy svn, but then we can't do a release until scipy
does...).
I know there has been some recent discussion and work on the scipy dev
list about a new package loading scheme, but am not sure what the
current status is (still in flux, finished). Robert or Travis, please
advise about the status of this module, and when you expect a scipy
release which has the new package loading scheme out.
JDH

Hi folks,
I just installed the latest svn/cvs scipy_core, scipy, and mpl
on OS 10.3.9, Py 2.4.1. There has been some shuffling around
of packages and package names in scipy in the last week or two,
and finally core+scipy is working without import complaints
(though 10 of the fftpack tests fail). However, now NOTHING
requiring pylab works---every attempt to import pylab eventually
fails with something like:
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/
__init__.py", line 143, in ?
 __import__('fft', g, l)
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/numerix/fft/
__init__.py", line 8, in ?
 from scipy.basic.fft import *
ImportError: No module named fft
Indeed, checking scipy verifies that scipy.basic.fft is now a 
*function* (ifft also); the module is fftpack (or fftpack_lite),
not fft:
>>> import scipy
>>> dir(scipy.basic)
['ScipyTest', '__builtins__', '__doc__', '__file__', '__name__', '__path__', 'fft', 'fftpack', 'fftpack_lite', 
'helper', 'ifft', 'lapack_lite', 'linalg', 'rand', 'randn', 'random', 'test']
>>> scipy.basic.fft
<function fft at 0x515470> 
I don't know who has to sort this out, scipy or mpl developers,
but I sure hope it can be done soon!
Thanks,
Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Oops; evidently tex_demo.py is supposed to *create* the .png
file---my bad. I was just having permission problems!!
Sorry for the distraction.
-Tom

Hi folks,
Just checked out mpl from CVS; tex_demo.py fails because it
cannot find tex_demo.png, which I know was in there a day or
so ago. Browsing on the SourceForge CVS portal, it isn't
shown there, so I don't think my CVS ignorance is behind this.
But it may be---let me know if you think so!
-Tom

Jouni K Seppanen <jk...@ik...> writes:
> #include <math.h>
> template<typename T> int mpl_isnan(T arg) { return isnan(arg); }
> #include <cmath>
Nah, that also effectively assumes the GNU libraries. Here's a better
idea:
#include <math.h>
int mpl_isnan_f(float f) { return isnan(f); }
int mpl_isnan_d(double f) { return isnan(f); }
int mpl_isnan_ld(long double f) { return isnan(f); }
Compile this as C(99), not C++, and put
extern "C" {
 int mpl_isnan_f(float);
 int mpl_isnan_d(double);
 int mpl_isnan_ld(long double);
}
in the C++ file.
-- 
Jouni

Tom Loredo <lo...@as...> writes:
> I'll try reinstalling the latest TeTeX; if anyone else has had such
> problems, I'd be grateful to know how you fixed them.
FWIW, I've had no problems with Gerben Wierda's i-Installer version of
TeX described at <http://ii2.sourceforge.net/tex-index.html>. I found
the installer program somewhat idiosyncratic, but once you figure that
out, you get a really nice TeX installation.
-- 
Jouni

Andrew Straw <str...@as...> writes:
> extern "C" {
> int isnan(double);
> }
>
>>Apparently, the upshot is that isnan is a C99 feature and C++ does not
>>incorporate C99.
>>
> So, does that mean the above should work on most C++ compilers? (Do
> they implement C99 mode when in extern "C" mode?) 
What extern "C" does is it disables the C++ name-mangling so you can
refer to C functions. The presence of isnan is a header/library issue,
and apparently the cmath header file in some systems makes sure to
hide isnan. It seems that C99 defines an isnan _macro_, and the above
is assuming that an isnan _function_ exists in the library. The isnan
manual page on OS X states:
| HISTORY
| 3BSD introduced isinf() and isnan() functions, which accepted double
| arguments; these have been superseded by the macros described above.
I don't know how widespread these functions are. GNU libc and OS X
have them, and all the world's either Linux or a Mac, right? :-)
I think we could use the system's isnan macro in a fairly clean way by
performing the following dance (untested, and I don't have an OS X
10.3 system to test on):
#include <math.h>
template<typename T> int mpl_isnan(T arg) { return isnan(arg); }
#include <cmath>
Is it possible in distutils to do autoconf-style compilation tests at
configuration time? 
-- 
Jouni

Andrew,
Thanks for the new patch. It works fine on OS 10.3.9/Python 2.4,
as far as I can tell. Cool!
My tex problem that originally motivated
the reinstall appears to be due to problems with my TeTeX 
install (dvipng is not finding mktex.opt and thus creating
blank PNGs, though ). I'll try reinstalling the latest TeTeX; if
anyone else has had such problems, I'd be grateful to know how
you fixed them.
-Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Referring to this:
>/ #include <math.h>
/32a34,37
>/ extern "C" {
/>/ int isnan(double);
/>/ }
/Jouni K Seppanen wrote:
>I suppose that would work, but then you will take a slight performance
>hit when calling isnan. It's probably not too bad; depends on how
>often it gets called.
> 
>
The code that makes use of isnan is not called enough to be worried 
about a minor speed hit.
>Apparently, the upshot is that isnan is a C99 feature and C++ does not
>incorporate C99.
>
So, does that mean the above should work on most C++ compilers? (Do 
they implement C99 mode when in extern "C" mode?) If so, I'm all for 
that approach as abandoning the isnan64 macro I borrowed from numarray. 
I'd rather take the minor speed hit than have all that intricate C 
coding currently in the MPL_isnan.h file.

Tom Loredo <lo...@as...> writes:
> http://www.ssl.berkeley.edu/pipermail/boinc_dev/2004-October/000529.html
>
> It involves including math.h and defining a prototype for isnan
> explicitly.
I suppose that would work, but then you will take a slight performance
hit when calling isnan. It's probably not too bad; depends on how
often it gets called.
Apple's cmath include file (my version of it, anyway, in
/usr/include/gcc/darwin/3.3/c++/) first defines a template function
that expands the macro, then undefines the macro and makes the
function available in the standard namespace (I've omitted a lot of
stuff here):
 namespace __gnu_cxx
 {
 template<typename _Tp>
 int 
 __capture_isnan(_Tp __f) { return isnan(__f); }
 }
 #undef isnan
 namespace __gnu_cxx
 {
 template<typename _Tp>
 int 
 isnan(_Tp __f) { return __capture_isnan(__f); }
 }
 namespace std
 {
 using __gnu_cxx::isnan;
 } 
So this ensures that when you call std::isnan, it is expanded at
compile-time to a call to __capture_isnan, which in turn is expanded
to the original isnan macro.
It also probably means that including math.h before cmath will have no
effect, since cmath will #undef the isnan macro. Including math.h
after cmath will also have no effect, since it is guarded with #ifndef
__MATH_H__.
The solution at the URL you mentioned adds a prototype for the isnan
function, which is included in the math library. I think it only
handles doubles, not floats or long doubles (and I have absolutely no
idea whether casting a float NaN to double works), and a function call
causes a minor performance hit. Other than that, I suppose that's
fine.
Somehow your cmath is failing to define isnan. At least in my version,
the definitions in __gnu_cxx (but not the #undef!) are conditioned on
 #if _GLIBCPP_USE_C99
Googling with that macro and isnan shows that a lot of other people
have been having similar problems. Another attempt at a solution is at
http://tolstoy.newcastle.edu.au/~rking/R/devel/05/01/1861.html
Another possibly relevant page is
http://lists.apple.com/archives/Xcode-users/2005/Feb/msg00238.html
Apparently, the upshot is that isnan is a C99 feature and C++ does not
incorporate C99. Perhaps the feature has been added anyway in some
version of gcc 3.3 between yours and mine.
-- 
Jouni

Tom Loredo <lo...@as...> writes:
> I've verified that the new "using std::isnan;" line is in _transforms.cpp
> and is copied to _na_transforms.cpp; it just doesn't seem to satisfy
> the compiler [gcc 3.3 20030304 (Apple Computer, Inc. build 1671) on 10.3.9].
> I'm not a c++ programmer, and I'm stumped as to what further to try.
> Jouni, did this indeed solve your build problems completely? Anyone
> have any other suggestions?
Yes, this solved my build problems, and the resulting library seems to
work. I also tried building with gcc 3.3 (gcc version 3.3 20030304
(Apple Computer, Inc. build 1809)).
Just to be sure, did you delete the "build" directory before trying
again? There could have been something left over that is causing the
error.
-- 
Jouni

OK, it seems trying to pick up "isnan" from the C/C++ stdlib is riddled
with difficulties, at least on Mac OS X.
Following numarray's lead, I've implemented our own test "MPL_isnan64".
This involved the addition of a new header file in src/ and the patch
I'm including. Also included in the patch (and also checked into CVS)
is the unit test which shows why this whole change is necessary.
This all works for me on Mac OS X 10.4 and Debian sarge AMD64. Tom,
maybe you could try it again on Mac OS X 10.3?
Cheers!
Andrew
Tom Loredo wrote:
>Andrew,
>
>Thanks for the suggestions, which proved helpful---transforms now
>builds; the rest of the build is proceeding and my fingers are
>crossed. Here's what I found/did.
>
>Including math.h did not help. Poking around with man and in /usr/include
>revealed that isnan is defined as a macro, not a function; math.h includes 
>/usr/include/architecture/ppc/math.h and the definition is in there. I
>did some googling and found one other case of this causing a problem;
>a workaround is provided here:
>
>http://www.ssl.berkeley.edu/pipermail/boinc_dev/2004-October/000529.html
>
>It involves including math.h and defining a prototype for isnan
>explicitly. I tried this and the build failed, but with a slightly
>different error:
>
>gcc: src/_na_transforms.cpp
>src/_na_transforms.cpp: In member function `Py::Object 
> Bbox::update_numerix(const Py::Tuple&)':
>src/_na_transforms.cpp:452: error: `isnan' not declared
>src/_na_transforms.cpp: In member function `Py::Object 
> Bbox::update_numerix(const Py::Tuple&)':
>src/_na_transforms.cpp:452: error: `isnan' not declared
>
>At this point, I commented out the "using..." line that was just
>added (reasoning that isnan is now in the file's namespace), and
>the build succeeded.
>
>I don't know the build process well enough to know if this can be
>easily automated in a cross-platform manner, or if there is a 
>better solution.
>
>As I write the numarray and scipy builds of _transforms.cpp have
>both succeeded. Hopefully that's the only stumbling block.
>
>-Tom
>
>
>
>-------------------------------------------------
>This mail sent through IMP: http://horde.org/imp/
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

Andrew,
Thanks for the suggestions, which proved helpful---transforms now
builds; the rest of the build is proceeding and my fingers are
crossed. Here's what I found/did.
Including math.h did not help. Poking around with man and in /usr/include
revealed that isnan is defined as a macro, not a function; math.h includes 
/usr/include/architecture/ppc/math.h and the definition is in there. I
did some googling and found one other case of this causing a problem;
a workaround is provided here:
http://www.ssl.berkeley.edu/pipermail/boinc_dev/2004-October/000529.html
It involves including math.h and defining a prototype for isnan
explicitly. I tried this and the build failed, but with a slightly
different error:
gcc: src/_na_transforms.cpp
src/_na_transforms.cpp: In member function `Py::Object 
 Bbox::update_numerix(const Py::Tuple&)':
src/_na_transforms.cpp:452: error: `isnan' not declared
src/_na_transforms.cpp: In member function `Py::Object 
 Bbox::update_numerix(const Py::Tuple&)':
src/_na_transforms.cpp:452: error: `isnan' not declared
At this point, I commented out the "using..." line that was just
added (reasoning that isnan is now in the file's namespace), and
the build succeeded.
I don't know the build process well enough to know if this can be
easily automated in a cross-platform manner, or if there is a 
better solution.
As I write the numarray and scipy builds of _transforms.cpp have
both succeeded. Hopefully that's the only stumbling block.
-Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Hmm... I've tested with gcc 3.3 on linux, so I'm not sure why it's breaking.
First, check if adding "#include <math.h>" will help.
Some other ideas:
 * Do "man isnan" from the command line and see if it specifies another
header file.
 * Search inside /usr/include for isnan and see what comes up.
Good luck,
Andrew
Tom Loredo wrote:
>Hi folks,
>
>Thanks for the quick help. I do also have numarray installed, so
>I don't think the NUMARRAY setting is the problem.
>
>Jouni, thanks for the attempted fix, but it continues to fail
>for me, at the same place:
>
>gcc: src/_na_transforms.cpp
>src/_na_transforms.cpp: In member function `Py::Object 
> Bbox::update_numerix(const Py::Tuple&)':
>src/_na_transforms.cpp:447: error: `isnan' not declared
>src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function)
>src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only 
> once for each function it appears in.)
>src/_na_transforms.cpp: In member function `Py::Object 
> Bbox::update_numerix(const Py::Tuple&)':
>src/_na_transforms.cpp:447: error: `isnan' not declared
>src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function)
>src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only 
> once for each function it appears in.)
>error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic 
>-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -I. -I/usr/local/include -I/usr/include -I/sw/include -I. -I/Library/
>Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/_na_transforms.cpp -o build/temp.darwin-7.9.0-
>Power_Macintosh-2.4/src/_na_transforms.o -DNUMARRAY=1" failed with exit status 1
>
>I've verified that the new "using std::isnan;" line is in _transforms.cpp
>and is copied to _na_transforms.cpp; it just doesn't seem to satisfy
>the compiler [gcc 3.3 20030304 (Apple Computer, Inc. build 1671) on 10.3.9].
>I'm not a c++ programmer, and I'm stumped as to what further to try.
>Jouni, did this indeed solve your build problems completely? Anyone
>have any other suggestions?
>
>Thanks,
>Tom
>
>
>-------------------------------------------------
>This mail sent through IMP: http://horde.org/imp/
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

Hi folks,
Thanks for the quick help. I do also have numarray installed, so
I don't think the NUMARRAY setting is the problem.
Jouni, thanks for the attempted fix, but it continues to fail
for me, at the same place:
gcc: src/_na_transforms.cpp
src/_na_transforms.cpp: In member function `Py::Object 
 Bbox::update_numerix(const Py::Tuple&)':
src/_na_transforms.cpp:447: error: `isnan' not declared
src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function)
src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only 
 once for each function it appears in.)
src/_na_transforms.cpp: In member function `Py::Object 
 Bbox::update_numerix(const Py::Tuple&)':
src/_na_transforms.cpp:447: error: `isnan' not declared
src/_na_transforms.cpp:494: error: `isnan' undeclared (first use this function)
src/_na_transforms.cpp:494: error: (Each undeclared identifier is reported only 
 once for each function it appears in.)
error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic 
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -I. -I/usr/local/include -I/usr/include -I/sw/include -I. -I/Library/
Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/_na_transforms.cpp -o build/temp.darwin-7.9.0-
Power_Macintosh-2.4/src/_na_transforms.o -DNUMARRAY=1" failed with exit status 1
I've verified that the new "using std::isnan;" line is in _transforms.cpp
and is copied to _na_transforms.cpp; it just doesn't seem to satisfy
the compiler [gcc 3.3 20030304 (Apple Computer, Inc. build 1671) on 10.3.9].
I'm not a c++ programmer, and I'm stumped as to what further to try.
Jouni, did this indeed solve your build problems completely? Anyone
have any other suggestions?
Thanks,
Tom
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Tom, thanks for the bug report and Jouni thanks for the fix, which I've
just checked in.
Cheers!
Andrew
Jouni K Seppanen wrote:
>Tom Loredo <lo...@as...> writes:
>
> 
>
>>I'm having trouble building the current CVS version of mpl
>>on OS X (10.3.9, Python 2.4). [...] numerix=scipy [...]
>>src/_na_transforms.cpp:493: error: `isnan' undeclared (first use this function)
>> 
>>
>
>I'm having the same problem in _nc_transforms.cpp, and I'm building on
>OS X 10.4.3, Python 2.4, gcc 4.0, and with -DNUMERIC=1 (no numarray,
>no scipy). It seems that the relevant lines in _transforms.cpp were
>last modified by astraw on 15-Dec-05.
>
>The following one-line change seems to fix that problem (but the rest
>of the build hasn't finished yet). I don't know what this does in
>other compilers, but comments in gcc's cmath suggest that the standard
>requires isnan to be in the std namespace.
>
> 
>
>------------------------------------------------------------------------
>
>Index: src/_transforms.cpp
>===================================================================
>RCS file: /cvsroot/matplotlib/matplotlib/src/_transforms.cpp,v
>retrieving revision 1.39
>diff -u -r1.39 _transforms.cpp
>--- src/_transforms.cpp	15 Dec 2005 04:54:52 -0000	1.39
>+++ src/_transforms.cpp	19 Dec 2005 06:14:42 -0000
>@@ -444,6 +444,7 @@
> Py::Object
> Bbox::update_numerix(const Py::Tuple &args) {
> //update the boox from the numerix arrays x and y
>+ using std::isnan;
> _VERBOSE("Bbox::update_numerix");
> 
> args.verify_length(3);
> 
>

Tom Loredo <lo...@as...> writes:
> I'm having trouble building the current CVS version of mpl
> on OS X (10.3.9, Python 2.4). [...] numerix=scipy [...]
> src/_na_transforms.cpp:493: error: `isnan' undeclared (first use this function)
I'm having the same problem in _nc_transforms.cpp, and I'm building on
OS X 10.4.3, Python 2.4, gcc 4.0, and with -DNUMERIC=1 (no numarray,
no scipy). It seems that the relevant lines in _transforms.cpp were
last modified by astraw on 15-Dec-05.
The following one-line change seems to fix that problem (but the rest
of the build hasn't finished yet). I don't know what this does in
other compilers, but comments in gcc's cmath suggest that the standard
requires isnan to be in the std namespace.
-- 
Jouni K Seppänen

Tom,
The output to gcc shows that NUMARRAY is defined. Try undefining NUMARRAY
and NUMERIC.
 -- Paul
On 12/18/05, Tom Loredo <lo...@as...> wrote:
>
>
> Hi folks,
>
> I'm having trouble building the current CVS version of mpl
> on OS X (10.3.9, Python 2.4). I am not using the 0.85 release
> because I want to use numerix=3Dscipy. I previously installed
> a CVS checkout from Dec 2, and it built fine. It seemed to
> plot fine, except that the TeX example produced blank or
> flat-line labels. I just installed the latest scipy_core
> release (and the latest scipy from svn), and also thought
> I'd try the latest mpl from CVS to see if the TeX problem was
> fixed. Now it won't build; about 6min into the build it exits:
>
> gcc: src/mplutils.cpp
> gcc: CXX/cxx_extensions.cxx
> gcc: src/_na_transforms.cpp
> src/_na_transforms.cpp: In member function `Py::Object
> Bbox::update_numerix(const Py::Tuple&)':
> src/_na_transforms.cpp:493: error: `isnan' undeclared (first use this
> function)
> src/_na_transforms.cpp:493: error: (Each undeclared identifier is reporte=
d
> only
> once for each function it appears in.)
> src/_na_transforms.cpp: In member function `Py::Object
> Bbox::update_numerix(const Py::Tuple&)':
> src/_na_transforms.cpp:493: error: `isnan' undeclared (first use this
> function)
> src/_na_transforms.cpp:493: error: (Each undeclared identifier is reporte=
d
> only
> once for each function it appears in.)
> error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp
> -mno-fused-madd -fno-common -dynamic
> -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -I. -I/usr/local/include
> -I/usr/include -I/sw/include -I. -I/Library/
> Frameworks/Python.framework/Versions/2.4/include/python2.4 -c
> src/_na_transforms.cpp -o build/temp.darwin-7.9.0-
> Power_Macintosh-2.4/src/_na_transforms.o -DNUMARRAY=3D1" failed with exit
> status 1
>
> I'd appreciate any help on how to fix this. I'm teaching a class
> of students using Python in about 4 weeks, and I need to provide
> them a version of things to set up on their laptops that I know
> will work with my examples.
>
> Thanks,
> Tom
>
> PS: If anyone has any tips on getting scipy to build properly on
> OS X, pass them along. The current version appears unable to find
> Apple's atlas, nor does it find the fftw libraries I installed in
> /usr/lib.
>
>
>
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Paul Barrett, PhD Johns Hopkins University
Assoc. Research Scientist Dept of Physics and Astronomy
Phone: 410-516-5190 Baltimore, MD 21218

Hi folks,
I'm having trouble building the current CVS version of mpl
on OS X (10.3.9, Python 2.4). I am not using the 0.85 release
because I want to use numerix=scipy. I previously installed
a CVS checkout from Dec 2, and it built fine. It seemed to
plot fine, except that the TeX example produced blank or
flat-line labels. I just installed the latest scipy_core
release (and the latest scipy from svn), and also thought
I'd try the latest mpl from CVS to see if the TeX problem was
fixed. Now it won't build; about 6min into the build it exits:
gcc: src/mplutils.cpp
gcc: CXX/cxx_extensions.cxx
gcc: src/_na_transforms.cpp
src/_na_transforms.cpp: In member function `Py::Object 
 Bbox::update_numerix(const Py::Tuple&)':
src/_na_transforms.cpp:493: error: `isnan' undeclared (first use this function)
src/_na_transforms.cpp:493: error: (Each undeclared identifier is reported only 
 once for each function it appears in.)
src/_na_transforms.cpp: In member function `Py::Object 
 Bbox::update_numerix(const Py::Tuple&)':
src/_na_transforms.cpp:493: error: `isnan' undeclared (first use this function)
src/_na_transforms.cpp:493: error: (Each undeclared identifier is reported only 
 once for each function it appears in.)
error: Command "gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic 
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -I. -I/usr/local/include -I/usr/include -I/sw/include -I. -I/Library/
Frameworks/Python.framework/Versions/2.4/include/python2.4 -c src/_na_transforms.cpp -o build/temp.darwin-7.9.0-
Power_Macintosh-2.4/src/_na_transforms.o -DNUMARRAY=1" failed with exit status 1
I'd appreciate any help on how to fix this. I'm teaching a class
of students using Python in about 4 weeks, and I need to provide
them a version of things to set up on their laptops that I know
will work with my examples.
Thanks,
Tom
PS: If anyone has any tips on getting scipy to build properly on
OS X, pass them along. The current version appears unable to find
Apple's atlas, nor does it find the fftw libraries I installed in
/usr/lib.
 
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/