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/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

Should be fixed now.

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

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 :wink: 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 :wink: 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 :wink: 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 :wink: 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