matplotlib-devel Mailing List for matplotlib (Page 3)

On Nov 27, 2007 2:05 PM, Charlie Moad <cw...@gm...> wrote:
> To clarify....
>
> - 0.91
> - numpy only
> - no wx compiled in (since 2.8 is pure python)
> - should tk use the default OSX installation for leopard?
Yes on the first three -- I am not sure what the last question is
referring to so perhaps you could elaborate.
JDH

To clarify....
- 0.91
- numpy only
- no wx compiled in (since 2.8 is pure python)
- should tk use the default OSX installation for leopard?
10.5 comes with a working freetype, but I was still going to
statically link it in for 10.4 users. It will be a FAT build.
- Charlie
On Nov 27, 2007 1:45 PM, John Hunter <jd...@gm...> wrote:
> On Nov 26, 2007 5:42 PM, Charles Moad <cw...@gm...> wrote:
> > 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.
>
> I just completed a successful test of r4472 so lets go ahead with the
> release on that version number.
>
> Thanks!
> JDH
>

On Nov 26, 2007 5:42 PM, Charles Moad <cw...@gm...> wrote:
> 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.
I just completed a successful test of r4472 so lets go ahead with the
release on that version number.
Thanks!
JDH

Charles Moad wrote:
> 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. 
Great!
A note about that -- I just built an app with Py2exe and delivered to 
someone that then couldn't run it, 'cause it's linked with the freetype 
in Apple's X11 -- I guess X11 isn't installed by default, so we really 
do need to keep that statically linked.
are libpng and libfreetype the only two we need now?
Charlie, is there somewhere I can get that built to try it out?
-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
Chr...@no...

 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

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
Chr...@no...

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

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
Chr...@no...

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

On Nov 26, 2007 3:49 PM, Christopher Barker <Chr...@no...> 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

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
Chr...@no...

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

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

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

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

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

[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

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

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.

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/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

On Thursday 22 November 2007 11:55:04 pm hjc520070 wrote:
> I just want to a dynamic plot with a line show in a plot.
> The line changes every second when it gets the different
> data(xdata(),ydata()) from list[i].
> list[1]=([1,2],[3,5]) list[2]=([1,2],[3,5],[5,4])
> list[3]=([1,2],[3,5],[5,4],[7,6])
> list[4]=([1,2],[3,5],[5,4],[7,6],[9,7])......
> for example, when list[1] in set for the data of the line, I will get a
> line with two point (1,2)(3,5). After a second,list[2] is auto setted for
> the data of the line, and I will get a line with three point. With the
> different list[i] setted for the line, the line changed.
> I just tried it again and again, but failed.
> Can somebody help me? And just give a short code to do it.
Coincidentally, I just posted some code recently that does this. See the 
thread titled "updating an image with a colorbar, performance issues", the 
script is called slow_test.py.
Darren