Thread: [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/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Nov 26, 2007 9:48 AM, Jeff Whitaker <js...@fa...> 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'

[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 <js...@fa...> 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

Should be fixed now.

Cheers,
Mike

John Hunter wrote:
> On Nov 26, 2007 9:48 AM, Jeff Whitaker <js...@fa...> 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  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

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  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

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  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

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  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg