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/PSD1 Email : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
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'
···
On Nov 26, 2007 9:48 AM, Jeff Whitaker <jswhit@...196...> wrote:
Michael: I'm seeing the following error on OS X (Tiger) with numpy
1.0.4 when building the latest svn 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 <jswhit@...196...> 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
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/PSD1 Email : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory
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
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/PSD1 Email : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory
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
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 <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?
-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/PSD1 Email : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory
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
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 <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
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/PSD1 Email : Jeffrey.S.Whitaker@...236...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory