Re: [matplotlib-devel] [Matplotlib-users] ANN: basemap toolkit version 0.9.7 released
Vincent Schut wrote: > Jeff Whitaker wrote: > > >> There is an extra dependency on the GEOS (Geometry Engine) library >> (http://geos.refractions.net). The source code is included with basemap, >> but requires a separate ./configure; make ;make install step before running >> setup.py. Using the GEOS library speeds up the creation of Basemap class >> instances dramatically, especially for small map regions using high >> resolution >> boundaries. >> >> > > Any chance on supporting geos-3.0-rc's? I'd prefer not to downgrade to > 2.2.3... > > Cheers, > Vincent. > > Vincent: Nope - sorry, but there are apparently still bugs in 3.0.0-rc4 that prevent basemap from working properly. You'll have to install 2.2.3 in a separate place - or just use the windows basemap installer which has 2.2.3 linked in statically. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/PSD1FAX : (303)497-6449 325 BroadwayBoulder, CO, USA 80305-3328 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: basemap toolkit version 0.9.7 released
Jeff Whitaker wrote: > Vincent Schut wrote: >> Jeff Whitaker wrote: >> >> >>> There is an extra dependency on the GEOS (Geometry Engine) library >>> (http://geos.refractions.net). The source code is included with >>> basemap, >>> but requires a separate ./configure; make ;make install step before >>> running >>> setup.py. Using the GEOS library speeds up the creation of Basemap >>> class >>> instances dramatically, especially for small map regions using high >>> resolution >>> boundaries. >>> >> >> Any chance on supporting geos-3.0-rc's? I'd prefer not to downgrade to >> 2.2.3... >> >> Cheers, >> Vincent. >> >> > Vincent: Nope - sorry, but there are apparently still bugs in 3.0.0-rc4 > that prevent basemap from working properly. You'll have to install > 2.2.3 in a separate place - or just use the windows basemap installer > which has 2.2.3 linked in statically. > > -Jeff > Alright, fair enough. Linux here, though, so I'll go for a downgrade. Don't like to have double versions of packages if I can avoid it. I'll manage, it's just that it is a bit of a hassle... Thanks, Vincent. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] build error in transforms branch
Michael: I'm seeing the following error on OS X (Tiger) with numpy 1.0.4 when building the latest svn transforms branch: src/path.cpp: In member function 'Py::Object _path_module::affine_transform(const Py::Tuple&)': src/path.cpp:700: error: invalid conversion from 'npy_intp*' to 'int*' cc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++ src/path.cpp: In member function 'Py::Object _path_module::affine_transform(const Py::Tuple&)': src/path.cpp:700: error: invalid conversion from 'npy_intp*' to 'int*' 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/include/python2.5 -c src/path.cpp -o build/temp.macosx-10.4-i386-2.5/src/path.o" failed with exit status 1 -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
On Nov 26, 2007 9:48 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: > > Michael: I'm seeing the following error on OS X (Tiger) with numpy > 1.0.4 when building the latest svn transforms branch: And in mostly unrelated news, I'm seeing the following traceback on zoom-to-rect from the toolbar in gtkagg on the transforms branch: AttributeError: 'TransformedBbox' object has no attribute 'get_bounds' Traceback (most recent call last): File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line 227, in motion_notify_event FigureCanvasBase.motion_notify_event(self, x, y) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py", line 941, in motion_notify_event self.callbacks.process(s, event) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/cbook.py", line 157, in process func(*args, **kwargs) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py", line 1359, in mouse_move self.draw_rubberband(event, x, y, lastx, lasty) File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", line 552, in draw_rubberband l,b,w,h = [int(val) for val in ax.bbox.get_bounds()] AttributeError: 'TransformedBbox' object has no attribute 'get_bounds' - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
[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 John Hunter wrote: > On Nov 26, 2007 9:48 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: >> Michael: I'm seeing the following error on OS X (Tiger) with numpy >> 1.0.4 when building the latest svn transforms branch: > > And in mostly unrelated news, I'm seeing the following traceback on > zoom-to-rect from the toolbar in gtkagg on the transforms branch: > > > AttributeError: 'TransformedBbox' object has no attribute 'get_bounds' > Traceback (most recent call last): > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", > line 227, in motion_notify_event > FigureCanvasBase.motion_notify_event(self, x, y) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py", > line 941, in motion_notify_event > self.callbacks.process(s, event) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/cbook.py", > line 157, in process > func(*args, **kwargs) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py", > line 1359, in mouse_move > self.draw_rubberband(event, x, y, lastx, lasty) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", > line 552, in draw_rubberband > l,b,w,h = [int(val) for val in ax.bbox.get_bounds()] > AttributeError: 'TransformedBbox' object has no attribute 'get_bounds' -- 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/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
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 -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
Should be fixed now. Cheers, Mike John Hunter wrote: > On Nov 26, 2007 9:48 AM, Jeff Whitaker <[EMAIL PROTECTED]> wrote: >> Michael: I'm seeing the following error on OS X (Tiger) with numpy >> 1.0.4 when building the latest svn transforms branch: > > And in mostly unrelated news, I'm seeing the following traceback on > zoom-to-rect from the toolbar in gtkagg on the transforms branch: > > > AttributeError: 'TransformedBbox' object has no attribute 'get_bounds' > Traceback (most recent call last): > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", > line 227, in motion_notify_event > FigureCanvasBase.motion_notify_event(self, x, y) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py", > line 941, in motion_notify_event > self.callbacks.process(s, event) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/cbook.py", > line 157, in process > func(*args, **kwargs) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py", > line 1359, in mouse_move > self.draw_rubberband(event, x, y, lastx, lasty) > File > "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", > line 552, in draw_rubberband > l,b,w,h = [int(val) for val in ax.bbox.get_bounds()] > AttributeError: 'TransformedBbox' object has no attribute 'get_bounds' -- 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/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
Sorry. Try now (r4447). I realised I have to skip even one more level. Cheers, Mike 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/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
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 >> >> > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
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 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/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
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! 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 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? -Jeff drive_gfs.o306841 > > 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 >>> >> >> > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
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 >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/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] build error in transforms branch
Michael Droettboom wrote: > 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 >>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 > Mike: Ah - I should have seen that. Looks like I might have to create a basemap-transforms branch. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] buglett/typo in axes.py
Hi all, I just noticed this in axes.py in SVN head, line 185: def __call__(self, *args, **kwargs): if self.axes.xaxis is not None and self.axes.xaxis is not None: I imagine that's supposed to check for xaxis and yaxis, not xaxis twice! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] buglett/typo in axes.py
On Nov 26, 2007 3:49 PM, Christopher Barker <[EMAIL PROTECTED]> wrote: > Hi all, > > I just noticed this in axes.py in SVN head, line 185: > > def __call__(self, *args, **kwargs): > > if self.axes.xaxis is not None and self.axes.xaxis is not None: > > > I imagine that's supposed to check for xaxis and yaxis, not xaxis twice! Yep, you are right. Thanks for catching it! Foxed in r4457 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] release plans
A couple of weeks ago we talked about doing a release, but with the deluge of changes (stix fonts, site.cfg, and others) I thought it might be a good idea to shake the tree for bugs. I think enough time has elapsed since these changes went in that we should proceed with the plan to release 0.91 if there are no objections. Charlie, what does your schedule look like? JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
Not that I've used one myself, but wouldn't this be most easily accomplished with a SVN commit hook -- i.e. whitespace would be stripped on every commit, rather than trying to enforce all developers setting up their editors correctly? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
Christopher Barker wrote: > Not that I've used one myself, but wouldn't this be most easily > accomplished with a SVN commit hook -- i.e. whitespace would be stripped > on every commit, rather than trying to enforce all developers setting up > their editors correctly? > > -Chris > > > That would be ideal, but it looks like sourceforge doesn't allow this, so we would have to move the project to another host. http://sourceforge.net/docs/E09#scripts Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Nabble - War on trailing whitespace]
Eric Firing wrote: > Christopher Barker wrote: >> Not that I've used one myself, but wouldn't this be most easily >> accomplished with a SVN commit hook > That would be ideal, but it looks like sourceforge doesn't allow this, > so we would have to move the project to another host. > > http://sourceforge.net/docs/E09#scripts Well, darn, That's a remarkably small list! Is there a way to petition them to add something else? oh well, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release plans
Ready whenever. I did a test 10.5 bulid a few days ago targeting 10.4 with the latest libpng and freetype statically linked in. All went pretty well. I'll write up build instructions similar to yours when I go through the motions again. - Charlie On Nov 26, 2007, at 4:55 PM, John Hunter wrote: > A couple of weeks ago we talked about doing a release, but with the > deluge of changes (stix fonts, site.cfg, and others) I thought it > might be a good idea to shake the tree for bugs. I think enough time > has elapsed since these changes went in that we should proceed with > the plan to release 0.91 if there are no objections. Charlie, what > does your schedule look like? > > JDH - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
