matplotlib-devel Mailing List for matplotlib

Darren Dale wrote:
> On Thursday 24 April 2008 03:09:43 pm John Hunter wrote:
>> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
>>> Darren,
>>>
>>> In an earlier thread on matplotlib-users, when this first came up, John
>>> noted that numpy svn should be required for present mpl svn, so
>>> instead of fixing the attempted workaround for 1.04 I took it out and
>>> instead put a numpy version check in matplotlib.__init__.
>> Just to make clear my thinking on this: since the svn trunk of mpl is
>> a major refactoring and will be a major point jump when we release it
>> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
>> can rely on all the nice features and fixes that have gone into that
>> release.
> 
> I've been installing numpy through various package managers and now I'll need 
> to figure out how to configure the build on fedora, ubuntu and gentoo in 
> order to use svn matplotlib. Was it a mistake for me to develop my 
> application using the matplotlib trunk? If I go through the trouble of 
> configuring the build environments for numpy on these various OS's, am I 
> going to discover that the numpy trunk is not backward compatible and is 
> causing problems with other applications? I know my own difficulties are not 
> sufficient reason to alter the development path of our fine library, but I 
> think this might be a mistake.
Darren,
It is open for discussion. Here are some factors:
1) In my experience, numpy is easy to build from source--easier than 
matplotlib.
2) The numpy 1.1 release is coming soon--on the order of a week. I 
don't know how much that will help you. Maybe not much until distro 
packages catch up, which can take a long time.
3) There have been a lot of bug fixes between numpy 1.04 and 1.1. The 
main area of *slight* incompatibility is in the masked array package. 
The main practical difference is that some import forms that worked with 
1.04 do not work with 1.1; e.g. you can't import ma from numpy.core 
because that is not where it is now, and it is sub-package, not a file. 
 The ma internals are quite different (a masked array is now a subclass 
of ndarray), and the overall implementation is much improved, but 
functions and methods are highly compatible.
Although I am sympathetic to the problems involved in making changes of 
this sort, I am also sympathetic to the problems of trying to keep 
something like mpl working with multiple versions of components like the 
numeric library. There were a lot of bugs and holes in the old 
numpy.ma. To me, it is a relief to be able to stick to the new version 
and forget about the limitations and quirks of the old. Ideally, it will 
mean that all of us can spend more time thinking about how to improve 
mpl and less time in duplicate testing and coming up with workarounds.
Eric

Hum, a quite common discussion (we have had it at the nipy sprint, for
instance). My feeling is that you want to avoid depending on SVN
versions, unless there is a huge gain. The reason is that you loose
tester and potential contributors. In addition it makes it harder to get
the whole stack in a consistent shape because everything becomes a moving
target.
My 2 cents,
Gaël

On Thursday 24 April 2008 03:09:43 pm John Hunter wrote:
> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
> > Darren,
> >
> > In an earlier thread on matplotlib-users, when this first came up, John
> > noted that numpy svn should be required for present mpl svn, so
> > instead of fixing the attempted workaround for 1.04 I took it out and
> > instead put a numpy version check in matplotlib.__init__.
>
> Just to make clear my thinking on this: since the svn trunk of mpl is
> a major refactoring and will be a major point jump when we release it
> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
> can rely on all the nice features and fixes that have gone into that
> release.
I've been installing numpy through various package managers and now I'll need 
to figure out how to configure the build on fedora, ubuntu and gentoo in 
order to use svn matplotlib. Was it a mistake for me to develop my 
application using the matplotlib trunk? If I go through the trouble of 
configuring the build environments for numpy on these various OS's, am I 
going to discover that the numpy trunk is not backward compatible and is 
causing problems with other applications? I know my own difficulties are not 
sufficient reason to alter the development path of our fine library, but I 
think this might be a mistake.

On Thu, Apr 24, 2008 at 3:32 PM, Eric Firing <ef...@ha...> wrote:
> Agreed. If there were a meta-class usage that was crystal-clear after a
> little inspection, and that actually made the code easier to understand and
> maintain, I would consider it.
>
> I know that when we talked in Kona I was complaining about decorators, but
> they are here to stay, and as long as they are not too tricky they can be
> fine. The @staticmethod form is an improvement over the non-decorator
> equivalent, an assignment at the bottom of the method. I would be happy to
> see Mike's commented-out @staticmethod lines uncommented, and the
> corresponding assignments at the bottom of the method deleted, for example.
>
> Requiring 2.4 would also let us remove the subprocess module--not a big
> deal, but an incremental simplification of the mpl package.
All these sound like good suggestions to me...
JDH

John Hunter wrote:
> On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote:
> 
>> On a related note, what about python >= 2.4 instead of 2.3? This is not
>> something I have a strong opinion about, but I think it might also be a
>> reasonable time to let 2.4 be the minimum requirement.
> 
> I think python 2.4 is totally reasonable for the 0.98 release, though
> I am still prone to avoiding certain magic like meta-classes where
> possible.
> 
> JDH
Agreed. If there were a meta-class usage that was crystal-clear after a 
little inspection, and that actually made the code easier to understand 
and maintain, I would consider it.
I know that when we talked in Kona I was complaining about decorators, 
but they are here to stay, and as long as they are not too tricky they 
can be fine. The @staticmethod form is an improvement over the 
non-decorator equivalent, an assignment at the bottom of the method. I 
would be happy to see Mike's commented-out @staticmethod lines 
uncommented, and the corresponding assignments at the bottom of the 
method deleted, for example.
Requiring 2.4 would also let us remove the subprocess module--not a big 
deal, but an incremental simplification of the mpl package.
Eric

On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote:
> On a related note, what about python >= 2.4 instead of 2.3? This is not
> something I have a strong opinion about, but I think it might also be a
> reasonable time to let 2.4 be the minimum requirement.
I think python 2.4 is totally reasonable for the 0.98 release, though
I am still prone to avoiding certain magic like meta-classes where
possible.
JDH

On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote:
> On a related note, what about python >= 2.4 instead of 2.3? This is not
> something I have a strong opinion about, but I think it might also be a
> reasonable time to let 2.4 be the minimum requirement.
As a point of reference, NumPy 1.2 will require python >= 2.4 and so
will the SciPy 0.7 release.
-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/

John Hunter wrote:
> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
>> Darren,
>>
>> In an earlier thread on matplotlib-users, when this first came up, John
>> noted that numpy svn should be required for present mpl svn, so
>> instead of fixing the attempted workaround for 1.04 I took it out and
>> instead put a numpy version check in matplotlib.__init__.
> 
> Just to make clear my thinking on this: since the svn trunk of mpl is
> a major refactoring and will be a major point jump when we release it
> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
> can rely on all the nice features and fixes that have gone into that
> release.
> 
> JDH
I agree completely!
On a related note, what about python >= 2.4 instead of 2.3? This is not 
something I have a strong opinion about, but I think it might also be a 
reasonable time to let 2.4 be the minimum requirement.
Eric

On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
> Darren,
>
> In an earlier thread on matplotlib-users, when this first came up, John
> noted that numpy svn should be required for present mpl svn, so
> instead of fixing the attempted workaround for 1.04 I took it out and
> instead put a numpy version check in matplotlib.__init__.
Just to make clear my thinking on this: since the svn trunk of mpl is
a major refactoring and will be a major point jump when we release it
(0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
can rely on all the nice features and fixes that have gone into that
release.
JDH

Darren,
In an earlier thread on matplotlib-users, when this first came up, John 
 noted that numpy svn should be required for present mpl svn, so 
instead of fixing the attempted workaround for 1.04 I took it out and 
instead put a numpy version check in matplotlib.__init__.
Eric
Darren Dale wrote:
> It looks like the recent modification to transforms.py to update datalims only 
> when valid data are available is broken for numpy-1.04. In 
> tranforms.Bbox.update_from_data_xy, with numpy-1.04, the following line:
> 
> xym = ma.masked_where(~npy.isfinite(xy), xy)
> 
> fails with:
> 
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2805, in 
> plot
> self.add_line(line)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1165, in 
> add_line
> self._update_line_limits(line)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1173, in 
> _update_line_limits
> self.update_datalim( xydata )
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1221, in 
> update_datalim
> self.dataLim.update_from_data_xy(xys, self.ignore_existing_data_limits)
> File "/usr/lib64/python2.5/site-packages/matplotlib/transforms.py", line 
> 699, in update_from_data_xy
> xym = ma.masked_where(~npy.isfinite(xy), xy)
> File "/usr/lib64/python2.5/site-packages/numpy/core/ma.py", line 641, in 
> __array_wrap__
> domain = ufunc_domain[func]
> KeyError: <ufunc 'isfinite'>
> 
> 
> It looks like isfinite doesnt like getting a masked array as input. Is xy 
> always a masked array? If so, maybe that line could look like:
> 
> xym = ma.masked_where(~npy.isfinite(xy.data), xy)
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Mike,
One of your cleanups might have introduced a problem?
Eric
Updated to revision 5071.
efiring@manini:~/programs/py/mpl/mpl_trunk$ psb
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98pre
 python: 2.5.1 (r251:54863, Mar 7 2008, 03:41:45) [GCC
 4.1.2 (Ubuntu 4.1.2-0ubuntu4)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.1.0.dev5061
 freetype2: 9.10.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.15beta5
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.1.1
 * WxAgg extension not required for wxPython >= 2.8
 Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.4,
 pygobject: 2.12.3
 Qt: Qt: 3.3.7, PyQt: 3.17
 Qt4: Qt: 4.2.2, PyQt4: 4.1
 Cairo: 1.2.0
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: present, version unknown
 pytz: 3371
OPTIONAL USETEX DEPENDENCIES
 dvipng: 1.9
 ghostscript: 8.15.4
 latex: 3.141592
 pdftops: 3.00
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.4.0
 enthought.traits: matplotlib will provide
[Edit setup.cfg to suppress the above messages]
============================================================================
running build
running build_py
copying lib/matplotlib/__init__.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/mathtext.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/mlab.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/backends/backend_wx.py -> 
build/lib.linux-i686-2.5/matplotlib/backends
copying lib/matplotlib/mpl-data/matplotlibrc -> 
build/lib.linux-i686-2.5/matplotlib/mpl-data
copying lib/matplotlib/mpl-data/matplotlib.conf -> 
build/lib.linux-i686-2.5/matplotlib/mpl-data
running build_ext
building 'matplotlib.ft2font' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/include/freetype2 -I/usr/local/include 
-I/usr/include -I. -I/usr/include/python2.5 -c src/ft2font.cpp -o 
build/temp.linux-i686-2.5/src/ft2font.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 build/temp.linux-i686-2.5/src/ft2font.o 
build/temp.linux-i686-2.5/src/mplutils.o 
build/temp.linux-i686-2.5/CXX/cxx_extensions.o 
build/temp.linux-i686-2.5/CXX/IndirectPythonInterface.o 
build/temp.linux-i686-2.5/CXX/cxxsupport.o 
build/temp.linux-i686-2.5/CXX/cxxextensions.o -L/usr/local/lib 
-lfreetype -lz -lstdc++ -lm -o 
build/lib.linux-i686-2.5/matplotlib/ft2font.so
building 'matplotlib.ttconv' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. 
-I/usr/include/python2.5 -c src/_ttconv.cpp -o 
build/temp.linux-i686-2.5/src/_ttconv.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. 
-I/usr/include/python2.5 -c ttconv/pprdrv_tt.cpp -o 
build/temp.linux-i686-2.5/ttconv/pprdrv_tt.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 build/temp.linux-i686-2.5/src/_ttconv.o 
build/temp.linux-i686-2.5/ttconv/pprdrv_tt.o 
build/temp.linux-i686-2.5/ttconv/pprdrv_tt2.o 
build/temp.linux-i686-2.5/ttconv/ttutil.o -L/usr/local/lib -o 
build/lib.linux-i686-2.5/matplotlib/ttconv.so
building 'matplotlib._path' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc 
-Iagg24/include -I. -I/usr/include/python2.5 -c agg24/src/agg_curves.cpp 
-o build/temp.linux-i686-2.5/agg24/src/agg_curves.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc 
-Iagg24/include -I. -I/usr/include/python2.5 -c src/path.cpp -o 
build/temp.linux-i686-2.5/src/path.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 
build/temp.linux-i686-2.5/agg24/src/agg_curves.o 
build/temp.linux-i686-2.5/agg24/src/agg_bezier_arc.o 
build/temp.linux-i686-2.5/agg24/src/agg_trans_affine.o 
build/temp.linux-i686-2.5/agg24/src/agg_vcgen_stroke.o 
build/temp.linux-i686-2.5/CXX/cxx_extensions.o 
build/temp.linux-i686-2.5/CXX/IndirectPythonInterface.o 
build/temp.linux-i686-2.5/CXX/cxxsupport.o 
build/temp.linux-i686-2.5/CXX/cxxextensions.o 
build/temp.linux-i686-2.5/src/path.o -L/usr/local/lib -lpng12 -lz 
-lstdc++ -lm -o build/lib.linux-i686-2.5/matplotlib/_path.so
building 'matplotlib.backends._backend_agg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc 
-Iagg24/include -I. -I/usr/include/freetype2 -I/usr/local/include 
-I/usr/include -I. -I/usr/include/python2.5 -c src/_image.cpp -o 
build/temp.linux-i686-2.5/src/_image.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
/usr/include/libpng12/pngconf.h:317: error: expected constructor, 
destructor, or type conversion before ‘.’ token
/usr/include/libpng12/pngconf.h:318: error: ‘__dont__’ does not name a type
error: command 'gcc' failed with exit status 1

It looks like the recent modification to transforms.py to update datalims only 
when valid data are available is broken for numpy-1.04. In 
tranforms.Bbox.update_from_data_xy, with numpy-1.04, the following line:
xym = ma.masked_where(~npy.isfinite(xy), xy)
fails with:
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2805, in 
plot
 self.add_line(line)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1165, in 
add_line
 self._update_line_limits(line)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1173, in 
_update_line_limits
 self.update_datalim( xydata )
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1221, in 
update_datalim
 self.dataLim.update_from_data_xy(xys, self.ignore_existing_data_limits)
 File "/usr/lib64/python2.5/site-packages/matplotlib/transforms.py", line 
699, in update_from_data_xy
 xym = ma.masked_where(~npy.isfinite(xy), xy)
 File "/usr/lib64/python2.5/site-packages/numpy/core/ma.py", line 641, in 
__array_wrap__
 domain = ufunc_domain[func]
KeyError: <ufunc 'isfinite'>
It looks like isfinite doesnt like getting a masked array as input. Is xy 
always a masked array? If so, maybe that line could look like:
xym = ma.masked_where(~npy.isfinite(xy.data), xy)

Paul Kienzle wrote:
> Hi,
>
> The superscripts in mpl don't seem to be placed at the correct height for
> small fonts. The y-tics on the attached plot shows this. The effect is
> similar in svg and pdf backends.
> 
Thanks. When looking up the x-height, the code was not taking the font 
size into account. This has been fixed on the branch and trunk.
> I'm using 0.91.2 because the latest svn version gives me a KeyError for
> ufunc isfinite.
> 
Can you provide the full traceback here so we can diagnose and fix this 
problem? The only reference to isfinite seems to be in the PDF backend, 
which is working for me, and is identical in 0.91.2 and trunk in that 
respect. There is probably a more complex Numpy version interaction 
going on.
Cheers,
Mike
> 	- Paul
>
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA