matplotlib-devel Mailing List for matplotlib (Page 497)

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/

On Dec 14, 2005, at 9:23 AM, Charlie Moad wrote:
> I missed the "New in version 2.4." note in the link I posted.  With
> this I would say the current state is probably worth keeping.

Attached is a script which I wrote to make setup.py's more  
declarative and to make using setuptools/py2exe/etc from one file  
less of a pain.  The important part is that it also backports  
"package_data" to Python 2.3, which could be ripped out and dropped  
into matplotlib's setup.py without too much trouble.

Ken

I missed the "New in version 2.4." note in the link I posted.  With
this I would say the current state is probably worth keeping.  Sorry
for the DoS attack of emails on the mailing list this morning. ;)

- Charlie

On 12/14/05, Charlie Moad <cw...@gm...> wrote:
> http://www.python.org/doc/current/dist/node11.html
>
> From this my impression is that the package data files will be placed
> in the same way they are in the package.  I will look for a way to get
> around this, and if anyone on the list knows how, please speak up.  As
> I said previously, my attempts to use "../../images/*" seemed not to
> work.
>
> On 12/14/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> >     Charlie> Before I do it, you do know that there will be no folder
> >     Charlie> heirarchy: e.g. fonts/ttf/*, images...  All files will be
> >     Charlie> in lib/matplotlib/mpl-data/.  I honestly don't think
> >     Charlie> there are terribly many files, so shouldn't be a huge
> >     Charlie> deal.
> >
> > Is this the only way to do it (no folder hierarchy?).  If so, I don't
> > see it as a show stopper.  But if it's possible, some form of
> > organization would be cleaner...
> >
> > JDH
> >
>

> try:
>     from setuptools.command import bdist_egg
>     #from setuptools import setup # use setuptools if possible
>     has_setuptools =3D True
> except ImportError:
>     from distutils.core import setup
>     has_setuptools =3D False
>

Won't setup not be defined if there is an ImportError? This instead?

try:
    from setuptools.command import bdist_egg
    has_setuptools =3D True
except ImportError:
    has_setuptools =3D False
from distutils.core import setup

http://www.python.org/doc/current/dist/node11.html

From this my impression is that the package data files will be placed
in the same way they are in the package.  I will look for a way to get
around this, and if anyone on the list knows how, please speak up.  As
I said previously, my attempts to use "../../images/*" seemed not to
work.

On 12/14/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
>     Charlie> Before I do it, you do know that there will be no folder
>     Charlie> heirarchy: e.g. fonts/ttf/*, images...  All files will be
>     Charlie> in lib/matplotlib/mpl-data/.  I honestly don't think
>     Charlie> there are terribly many files, so shouldn't be a huge
>     Charlie> deal.
>
> Is this the only way to do it (no folder hierarchy?).  If so, I don't
> see it as a show stopper.  But if it's possible, some form of
> organization would be cleaner...
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> Before I do it, you do know that there will be no folder
    Charlie> heirarchy: e.g. fonts/ttf/*, images...  All files will be
    Charlie> in lib/matplotlib/mpl-data/.  I honestly don't think
    Charlie> there are terribly many files, so shouldn't be a huge
    Charlie> deal.

Is this the only way to do it (no folder hierarchy?).  If so, I don't
see it as a show stopper.  But if it's possible, some form of
organization would be cleaner...

JDH

Before I do it, you do know that there will be no folder heirarchy:
e.g. fonts/ttf/*, images...
All files will be in lib/matplotlib/mpl-data/.  I honestly don't think
there are terribly many files, so shouldn't be a huge deal.

- Charlie

On 12/14/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
>     Charlie> Btw, the best approach would to specify the data as
>     Charlie> package-data (since that is what it is), and it would be
>     Charlie> the most compatible.  Unfortunately my attempt to use
>     Charlie> parent directory relative paths failed.  Taking this
>     Charlie> approach would actually require moving all the mpl data
>     Charlie> into the lib/matplotlib/mpl-data directory in cvs.  I
>     Charlie> thought you might be opposed to that, hence I have the
>     Charlie> logic in the setup file.
>
>
> I'm happy to do it in the cleanest and best way so feel free to
> reorganize as necessary, as long as we continue to test on the various
> platforms as you have been doing.  You'll need to submit an admin
> request to the sf developers to flush the unused CVS directories after
> the reorganization.
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> Btw, the best approach would to specify the data as
    Charlie> package-data (since that is what it is), and it would be
    Charlie> the most compatible.  Unfortunately my attempt to use
    Charlie> parent directory relative paths failed.  Taking this
    Charlie> approach would actually require moving all the mpl data
    Charlie> into the lib/matplotlib/mpl-data directory in cvs.  I
    Charlie> thought you might be opposed to that, hence I have the
    Charlie> logic in the setup file.


I'm happy to do it in the cleanest and best way so feel free to
reorganize as necessary, as long as we continue to test on the various
platforms as you have been doing.  You'll need to submit an admin
request to the sf developers to flush the unused CVS directories after
the reorganization.

JDH

Btw, the best approach would to specify the data as package-data
(since that is what it is), and it would be the most compatible.=20
Unfortunately my attempt to use parent directory relative paths
failed.  Taking this approach would actually require moving all the
mpl data into the lib/matplotlib/mpl-data directory in cvs.  I thought
you might be opposed to that, hence I have the logic in the setup
file.

- Charlie

On 12/14/05, Charlie Moad <cw...@gm...> wrote:
> That seems a better approach.  Did you commit?
>
> On 12/14/05, John Hunter <jdh...@ac...> wrote:
> > >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
> >
> >     Charlie>      I just committed my changes.  The simplest approach
> >     Charlie> would be to specify the matplotlib module package_data,
> >     Charlie> but the current cvs layout doesn't tailor to that very
> >     Charlie> well.  So I mimicked distutils install command to
> >     Charlie> determine where matplotlib is installed.  The datapath is
> >     Charlie> then defined as $platlib/matplotlib/mpl-data.  Why this
> >     Charlie> change?  If you take a look at
> >     Charlie> matplotlib._get_data_path() you will see.  This method
> >     Charlie> has grown to probably 100 lines of code to check for
> >     Charlie> various cases, e.g. py2exe, setuptools, embedding mpl,
> >     Charlie> etc.  Now that the data is installed into the matplotlib
> >     Charlie> module you could pretty much reduce to 1 line:
> >     Charlie> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])".
> >     Charlie> This now handles all the cases mentioned above.  I left
> >     Charlie> in the initial check for the MATPLOTLIBDATA env key to
> >     Charlie> still allow for some flexibility.  I have tested on posix
> >     Charlie> and w/wo setuptools.  I am going to check windows right
> >     Charlie> now, but pretty sure it should work.  Please check this
> >     Charlie> very carefully before next release as it is a pretty
> >     Charlie> major change.  Let me know if anyone encounters a
> >     Charlie> problem.
> >
> > I'm having some trouble with this on my system.  I don't know if
> > something is screwy with my setuptools because I have setuptools but I
> > don't have egg
> >
> > peds-pc311:~/python/projects/matplotlib> python
> > Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
> > [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import setuptools
> > >>> from setuptools.command import bdist_egg
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > ImportError: cannot import name bdist_egg
> > >>>
> >
> > and my install fails
> >
> > peds-pc311:~/python/projects/matplotlib> sudo python setup.py install
> > installing data to ./matplotlib/mpl-data
> > running install
> > running build
> > running build_py
> > running build_ext
> > running install_lib
> > running install_data
> > copying matplotlibrc -> /usr/./matplotlib/mpl-data
> >
> >
> > So I replaced the has_setup check with this
> >
> > try:
> >     from setuptools.command import bdist_egg
> >     #from setuptools import setup # use setuptools if possible
> >     has_setuptools =3D True
> > except ImportError:
> >     from distutils.core import setup
> >     has_setuptools =3D False
> >
> >
> > which works on my system.  I hit the same bug with scipy, and the
> > moral seems to be that you should explicitly check for eggs rather
> > than just setuptools, because there are some versions of setuptools
> > floating around w/o eggs.
> >
> > JDH
> >
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> That seems a better approach.  Did you commit?

Not yet, but I will.

JDH

That seems a better approach.  Did you commit?

On 12/14/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
>     Charlie>      I just committed my changes.  The simplest approach
>     Charlie> would be to specify the matplotlib module package_data,
>     Charlie> but the current cvs layout doesn't tailor to that very
>     Charlie> well.  So I mimicked distutils install command to
>     Charlie> determine where matplotlib is installed.  The datapath is
>     Charlie> then defined as $platlib/matplotlib/mpl-data.  Why this
>     Charlie> change?  If you take a look at
>     Charlie> matplotlib._get_data_path() you will see.  This method
>     Charlie> has grown to probably 100 lines of code to check for
>     Charlie> various cases, e.g. py2exe, setuptools, embedding mpl,
>     Charlie> etc.  Now that the data is installed into the matplotlib
>     Charlie> module you could pretty much reduce to 1 line:
>     Charlie> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])".
>     Charlie> This now handles all the cases mentioned above.  I left
>     Charlie> in the initial check for the MATPLOTLIBDATA env key to
>     Charlie> still allow for some flexibility.  I have tested on posix
>     Charlie> and w/wo setuptools.  I am going to check windows right
>     Charlie> now, but pretty sure it should work.  Please check this
>     Charlie> very carefully before next release as it is a pretty
>     Charlie> major change.  Let me know if anyone encounters a
>     Charlie> problem.
>
> I'm having some trouble with this on my system.  I don't know if
> something is screwy with my setuptools because I have setuptools but I
> don't have egg
>
> peds-pc311:~/python/projects/matplotlib> python
> Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
> [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import setuptools
> >>> from setuptools.command import bdist_egg
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: cannot import name bdist_egg
> >>>
>
> and my install fails
>
> peds-pc311:~/python/projects/matplotlib> sudo python setup.py install
> installing data to ./matplotlib/mpl-data
> running install
> running build
> running build_py
> running build_ext
> running install_lib
> running install_data
> copying matplotlibrc -> /usr/./matplotlib/mpl-data
>
>
> So I replaced the has_setup check with this
>
> try:
>     from setuptools.command import bdist_egg
>     #from setuptools import setup # use setuptools if possible
>     has_setuptools =3D True
> except ImportError:
>     from distutils.core import setup
>     has_setuptools =3D False
>
>
> which works on my system.  I hit the same bug with scipy, and the
> moral seems to be that you should explicitly check for eggs rather
> than just setuptools, because there are some versions of setuptools
> floating around w/o eggs.
>
> JDH
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie>      I just committed my changes.  The simplest approach
    Charlie> would be to specify the matplotlib module package_data,
    Charlie> but the current cvs layout doesn't tailor to that very
    Charlie> well.  So I mimicked distutils install command to
    Charlie> determine where matplotlib is installed.  The datapath is
    Charlie> then defined as $platlib/matplotlib/mpl-data.  Why this
    Charlie> change?  If you take a look at
    Charlie> matplotlib._get_data_path() you will see.  This method
    Charlie> has grown to probably 100 lines of code to check for
    Charlie> various cases, e.g. py2exe, setuptools, embedding mpl,
    Charlie> etc.  Now that the data is installed into the matplotlib
    Charlie> module you could pretty much reduce to 1 line:
    Charlie> "os.sep.join([os.path.dirname(__file__), 'mpl-data'])".
    Charlie> This now handles all the cases mentioned above.  I left
    Charlie> in the initial check for the MATPLOTLIBDATA env key to
    Charlie> still allow for some flexibility.  I have tested on posix
    Charlie> and w/wo setuptools.  I am going to check windows right
    Charlie> now, but pretty sure it should work.  Please check this
    Charlie> very carefully before next release as it is a pretty
    Charlie> major change.  Let me know if anyone encounters a
    Charlie> problem.

I'm having some trouble with this on my system.  I don't know if
something is screwy with my setuptools because I have setuptools but I
don't have egg

peds-pc311:~/python/projects/matplotlib> python
Python 2.4.1 (#2, Mar 30 2005, 21:51:10)
[GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import setuptools
>>> from setuptools.command import bdist_egg
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: cannot import name bdist_egg
>>>

and my install fails

peds-pc311:~/python/projects/matplotlib> sudo python setup.py install
installing data to ./matplotlib/mpl-data
running install
running build
running build_py
running build_ext
running install_lib
running install_data
copying matplotlibrc -> /usr/./matplotlib/mpl-data


So I replaced the has_setup check with this

try:
    from setuptools.command import bdist_egg    
    #from setuptools import setup # use setuptools if possible
    has_setuptools = True
except ImportError:
    from distutils.core import setup
    has_setuptools = False


which works on my system.  I hit the same bug with scipy, and the
moral seems to be that you should explicitly check for eggs rather
than just setuptools, because there are some versions of setuptools
floating around w/o eggs.

JDH

 

Has anyone worked with quotes_historical_yahoo module enough to know if the
7th  attribute, adjusted price, is available? Adjusted price is sort of a
total return figure -- price adjusted for splits and dividends -- and is
actually the critical number to consider for performance over long periods
of time. Finance.quothist in Perl provides this attribute as an option.

 

Steve Miller 

Charlie Moad wrote:
> That's great to hear!  Thanks for the info.  I am just surprised I
> have not seen this response when it has came up on the twisted list.

I, too, find that bizarre since Twisted and Zope were *the* reasons for that
feature.

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

That's great to hear!  Thanks for the info.  I am just surprised I
have not seen this response when it has came up on the twisted list.

- Charlie

On 12/12/05, Robert Kern <rob...@gm...> wrote:
> Charlie Moad wrote:
> >      The way mpl uses the basemap toolkit will not work using
> > setuptools.  This is also an issue that twisted runs into.  Since
> > matplotlib will be put in one egg folder and basemap will be stuck in
> > another, trying to import matplotlib.toolkits.basemap will yield an
> > error.  Just something to think about for down the road, but its
> > probably not a priority now.
>
> That's why setuptools/eggs have the concept of namespace packages. Both t=
he
> matplotlib egg and basemap egg provide the matplotlib.toolkits namespace =
package.
>
> E.g.:
>
> setup(#...
>       namespace_packages=3D['matplotlib.toolkits'],
> )
>
> --
> Robert Kern
> rob...@gm...
>
> "In the fields of hell where the grass grows high
>  Are the graves of dreams allowed to die."
>   -- Richard Harter
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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
>

Charlie Moad wrote:
>      The way mpl uses the basemap toolkit will not work using
> setuptools.  This is also an issue that twisted runs into.  Since
> matplotlib will be put in one egg folder and basemap will be stuck in
> another, trying to import matplotlib.toolkits.basemap will yield an
> error.  Just something to think about for down the road, but its
> probably not a priority now.

That's why setuptools/eggs have the concept of namespace packages. Both the
matplotlib egg and basemap egg provide the matplotlib.toolkits namespace package.

E.g.:

setup(#...
      namespace_packages=['matplotlib.toolkits'],
)

-- 
Robert Kern
rob...@gm...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter