Jeff Whitaker wrote: > Michael Droettboom wrote: >> Actually, this is the inverse error to the other one ;) Keeping track >> of which APIs are "current" is proving difficult. >> >> Try r4448... Thanks for your patience. >> >> Cheers, >> Mike > > Mike: That did it now, thanks!
Phew! > Now trying the basemap examples, I see > that very often I assume that ax.get_position() returns a tuple, but now > it returns a Bbox instance. So, I get errors like this > > File "contour_demo.py", line 25, in <module> > l,b,w,h=ax.get_position() > TypeError: 'Bbox' object is not iterable > > Is that an API change that I need to adjust to, or a bug? That's an API change. There's a list of changes related to the transforms branch at the top of API_CHANGES. There's a lot of them, but they all follow a pretty similar pattern. I've been secretly worried that these changes will make life difficult for large bits of third-party code (like basemap). If any of these changes makes something much harder to do than it used to be, please let me know, and we can find a solution. None of this is set in stone, obviously, since it's still and experimental branch. Cheers, Mike >> >> Jeff Whitaker wrote: >>> Michael Droettboom wrote: >>>> Sorry. Try now (r4447). I realised I have to skip even one more >>>> level. >>>> >>>> Cheers, >>>> Mike >>> >>> Mike: Got a bit further this time, then hit the same error in >>> backend_agg.cpp: >>> >>> src/backend_agg.cpp: In member function 'Py::Object >>> RendererAgg::draw_quad_mesh(const Py::Tuple&)': >>> src/backend_agg.cpp:1208: error: invalid conversion from 'int*' to >>> 'npy_intp*' >>> src/backend_agg.cpp:1214: error: invalid conversion from 'int*' to >>> 'npy_intp*' >>> cc1plus: warning: command line option "-Wstrict-prototypes" is valid >>> for C/ObjC but not for C++ >>> src/backend_agg.cpp: In member function 'Py::Object >>> RendererAgg::draw_quad_mesh(const Py::Tuple&)': >>> src/backend_agg.cpp:1208: error: invalid conversion from 'int*' to >>> 'npy_intp*' >>> src/backend_agg.cpp:1214: error: invalid conversion from 'int*' to >>> 'npy_intp*' >>> error: Command "gcc -fno-strict-aliasing -Wno-long-double >>> -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall >>> -Wstrict-prototypes >>> -I/sw/lib/python2.5/site-packages/numpy/core/include >>> -I/sw/include/libpng12 -I/sw/lib/freetype219/include -I/usr/include >>> -I/sw/include -I/usr/X11R6/include -I. >>> -I/sw/lib/python2.5/site-packages/numpy/core/include -Isrc >>> -Iagg24/include -I. -I/sw/lib/freetype219/include -I/usr/include >>> -I/sw/include -I/usr/X11R6/include -I. >>> -I/sw/lib/python2.5/site-packages/numpy/core/include/freetype2 >>> -I/sw/include/libpng12/freetype2 >>> -I/sw/lib/freetype219/include/freetype2 -I/usr/include/freetype2 >>> -I/sw/include/freetype2 -I/usr/X11R6/include/freetype2 -I./freetype2 >>> -I/sw/lib/python2.5/site-packages/numpy/core/include/freetype2 >>> -Isrc/freetype2 -Iagg24/include/freetype2 -I./freetype2 >>> -I/sw/lib/freetype219/include/freetype2 -I/usr/include/freetype2 >>> -I/sw/include/freetype2 -I/usr/X11R6/include/freetype2 -I./freetype2 >>> -I/sw/include/python2.5 -c src/backend_agg.cpp -o >>> build/temp.macosx-10.4-i386-2.5/src/backend_agg.o" failed with exit >>> status 1 >>> >>> -Jeff >>> >>>> >>>> Jeff Whitaker wrote: >>>>> Michael Droettboom wrote: >>>>>> [Jeff -- I don't know why your original e-mail never got delivered >>>>>> to me, but I was able to see it in the archive.] >>>>>> >>>>>> The problem arises on platforms with 64-bit pointers -- in Numpy >>>>>> the datatype used to store the shape of an array is different from >>>>>> the datatype used to specify the shape of an array. (I presume >>>>>> this difference is to maintain backward compatibility, but I'll >>>>>> probably fire an e-mail off on the Numpy list). >>>>>> >>>>>> There is a possible fix for this in SVN r4445. Can you please let >>>>>> me know if that works for you? >>>>>> >>>>>> Cheers, >>>>>> Mike >>>>> >>>>> Mike: I still get the same error with r4445. >>>>> -Jeff >>>>> >>>>> >>>> >>> >>> >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
