matplotlib-devel Mailing List for matplotlib (Page 7)

Looks very nice! We'd love to have smarter layout systems as we 
create a lot of plots for people (i.e. standard scripts that people 
run instead of edit) and it's difficult to apply nice layouts that 
work for every case that comes up.
Can any of this be extended to make the auto-ticking algorithms smart 
enough to not overlap tick mark text fields so much? We get this all 
the time with date plots and it drives people nuts.
Ted
At 01:50 PM 12/4/2007, Michael Droettboom wrote:
>I have implemented (experimental) support for auto-shrinking of axes 
>to prevent their tick labels, axis labels and titles from 
>overlapping other axes. It's been tested on everything in 
>backend_driver.py and seems to work fairly well, with a few minor 
>glitches related to fixed aspect ratio axes and colorbars.
>
>The important user-visible change is that the position of an axes 
>(as set by axes([l, b, w, h])) is now inclusive of the axis labels, 
>tick labels and axes title. The auto-layout algorithm prevents 
>(well, reduces) any of the text from going outside of that 
>bounds. I couldn't figure out a good to maintain the old 
>convention, where the axes position is the position of only the 
>"data" area, since it makes it unclear, particularly with multi-axes 
>figures, when text should be considered "out of bounds". With 
>respect to the examples, this only affected a few of them where the 
>position of the axes was manually nudged to make room for 
>text. Simply removing those lines results in better-looking 
>plots. Maybe this API change doesn't matter, but if it does, we can 
>brainstorm ways around it. I'd prefer not to keep both ways alive 
>indefinitely, but perhaps there is a good argument for that anyway.
>
>One of the considerations I made was to keep the axes aligned with 
>one another. For example, if you have two axes stacked on top of 
>one another, and one axes has large numbers on the y-axis, but the 
>other does not, the left edge of both axes' data areas should remain 
>aligned. The layout algorithm ensures that if an edge of an axes 
>was aligned with other axes to begin with, it will always remain 
>so. This applies whether the axes position was specified with 
>"axes([l, b, w, h])" or "subplot(121)", or "axes().set_position([l, b, w, h])".
>
>Attached is an example where tick labels have been put in weird 
>places to demonstrate how all this works, with before and after pictures.
>
>Cheers,
>Mike
>
>--
>Michael Droettboom
>Science Software Branch
>Operations and Engineering Division
>Space Telescope Science Institute
>Operated by AURA for NASA
>
>
>
>#!/usr/bin/env python """ Example: simple line plot. Show how to 
>make and save a simple line plot with labels, title and grid """ 
>from pylab import * t = arange(0.0, 1.0+0.01, 0.01) s = 
>cos(2*2*pi*t) ax1 = subplot(211) plot(t, s, '-', lw=2) 
>xlabel('xlabel for bottom axes') ylabel('ylabel on the right') 
>title('About as simple as it gets, folks') grid(True) 
>ax1.yaxis.set_label_position('right') 
>ax1.xaxis.set_ticklabels(['Monday', 'Tuesday', 'Wednesday', 
>'Thursday', 'Friday']) for label in 
>ax1.get_xticklabels(): label.set_rotation(45) ax2 = subplot(212) 
>plot(t, s, '-', lw=2) grid(True) xlabel('xlabel for bottom axes (the 
>ticks are on the top for no good reason)') ylabel('I\'m a lefty') 
>ax2.xaxis.set_label_position('bottom') 
>ax2.xaxis.set_ticks_position('top') #savefig('simple_plot.png') 
>savefig('simple_plot') show()
>-------------------------------------------------------------------------
>SF.Net email is sponsored by: The Future of Linux Business White Paper
>from Novell. From the desktop to the data center, Linux is going
>mainstream. Let it simplify your IT future.
>http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

I have implemented (experimental) support for auto-shrinking of axes to 
prevent their tick labels, axis labels and titles from overlapping other 
axes. It's been tested on everything in backend_driver.py and seems to 
work fairly well, with a few minor glitches related to fixed aspect 
ratio axes and colorbars.
The important user-visible change is that the position of an axes (as 
set by axes([l, b, w, h])) is now inclusive of the axis labels, tick 
labels and axes title. The auto-layout algorithm prevents (well, 
reduces) any of the text from going outside of that bounds. I couldn't 
figure out a good to maintain the old convention, where the axes 
position is the position of only the "data" area, since it makes it 
unclear, particularly with multi-axes figures, when text should be 
considered "out of bounds". With respect to the examples, this only 
affected a few of them where the position of the axes was manually 
nudged to make room for text. Simply removing those lines results in 
better-looking plots. Maybe this API change doesn't matter, but if it 
does, we can brainstorm ways around it. I'd prefer not to keep both 
ways alive indefinitely, but perhaps there is a good argument for that 
anyway.
One of the considerations I made was to keep the axes aligned with one 
another. For example, if you have two axes stacked on top of one 
another, and one axes has large numbers on the y-axis, but the other 
does not, the left edge of both axes' data areas should remain aligned. 
 The layout algorithm ensures that if an edge of an axes was aligned 
with other axes to begin with, it will always remain so. This applies 
whether the axes position was specified with "axes([l, b, w, h])" or 
"subplot(121)", or "axes().set_position([l, b, w, h])".
Attached is an example where tick labels have been put in weird places 
to demonstrate how all this works, with before and after pictures.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Dec 4, 2007 2:17 PM, Darren Dale <dar...@co...> wrote:
> I'm checking the matplotlib-0.91.1 gentoo ebuild that S=E9bastien Fabbro =
put
> together. After installing, I get a number of errors when running
> backend_driver.py that are probably related to MANIFEST.in: missing pyplo=
t
> and npyma. There are many other errors exposed by backend_driver as well,=
 but
> maybe some will clear up with an improved MANIFEST.
Could you post some of the errors?
Thanks,
JDH

Darren Dale wrote:
> I'm checking the matplotlib-0.91.1 gentoo ebuild that Sébastien Fabbro put 
> together. After installing, I get a number of errors when running 
> backend_driver.py that are probably related to MANIFEST.in: missing pyplot 
> and npyma. There are many other errors exposed by backend_driver as well, but 
> maybe some will clear up with an improved MANIFEST.
pyplot.py is in lib, and MANIFEST.in already recursively includes 
everything in lib, so I don't think this is the problem.
npyma is inside of lib/numerix/, which again should not have required 
any change to MANIFEST.in.
Eric

On Tuesday 04 December 2007 9:18:14 am John Hunter wrote:
> Charlie is fixing a few problems with the release, and noticed that
> many of the new directories and files that have been created of late
> were not added to MANIFEST.in, which is used by sdist in the build
> process to build a correct source distribution. He added a few things
> (eg ttconv and setup.cfg.template) but please take a look over this
> file if you have made significant additions or reorganizations in the
> last 6 months to make sure everything is there. It picks up pattern
> matches recursively so it is usually enough to update with a new dir
> or wildcard, but please maintain this file as you contribute. It's
> easy to forget if you are not involved in the build, so I'll update
> the CODING_GUIDE
I'm checking the matplotlib-0.91.1 gentoo ebuild that S=E9bastien Fabbro pu=
t=20
together. After installing, I get a number of errors when running=20
backend_driver.py that are probably related to MANIFEST.in: missing pyplot=
=20
and npyma. There are many other errors exposed by backend_driver as well, b=
ut=20
maybe some will clear up with an improved MANIFEST.
Charlie, will you have time to upload an improved src distribution any time=
=20
soon?
Darren

Thanks. Fixed in r4590.
Cheers,
Mike
Jeff Whitaker wrote:
> Mike:
> 
> shading='faceted' doesn't work (no edges are drawn around the polygons).
> 
> -Jeff
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Charlie is fixing a few problems with the release, and noticed that
many of the new directories and files that have been created of late
were not added to MANIFEST.in, which is used by sdist in the build
process to build a correct source distribution. He added a few things
(eg ttconv and setup.cfg.template) but please take a look over this
file if you have made significant additions or reorganizations in the
last 6 months to make sure everything is there. It picks up pattern
matches recursively so it is usually enough to update with a new dir
or wildcard, but please maintain this file as you contribute. It's
easy to forget if you are not involved in the build, so I'll update
the CODING_GUIDE
JDH

Mike:
shading='faceted' doesn't work (no edges are drawn around the polygons).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Michael Droettboom wrote:
> The transforms branch has seen very little outside of the matplotlib 
> examples, so it's good to find all of these error cases. Fixed in r4569.
>
> Cheers,
> Mike
>
>> Michael: And one more - contourf will die if you there are no 
>> contours at the requested levels. The error message looks like this:
>>
>> Traceback (most recent call last):
>> File "plotprecip.py", line 52, in <module>
>> cs = m.contourf(x,y,data,clevs,cmap=cm.s3pcpn)
>> File "/Users/jsw/lib/python/matplotlib/toolkits/basemap/basemap.py", 
>> line 2425, in contourf
>> CS = ax.contourf(x,y,data,*args,**kwargs)
>> File "/Users/jsw/lib/python/matplotlib/axes.py", line 5017, in contourf
>> return mcontour.ContourSet(self, *args, **kwargs)
>> File "/Users/jsw/lib/python/matplotlib/contour.py", line 460, in 
>> __init__
>> self.ax.add_collection(col)
>> File "/Users/jsw/lib/python/matplotlib/axes.py", line 1140, in 
>> add_collection
>> self.update_datalim(collection.get_datalim(self.transData))
>> File "/Users/jsw/lib/python/matplotlib/collections.py", line 142, in 
>> get_datalim
>> offsets, transOffset.frozen())
>> File "/Users/jsw/lib/python/matplotlib/path.py", line 481, in 
>> get_path_collection_extents
>> raise ValueError("No paths provided")
>>
>> To trigger this, try running the plotprecip.py basemap example.
>>
>> -Jeff
>>
>
Michael: The fix for missing contours may have broken pcolor:
Traceback (most recent call last):
 File "test.py", line 553, in <module>
 p = m.pcolormesh(x,y,topodatin,shading='flat')
 File "/Users/jsw/lib/python/matplotlib/toolkits/basemap/basemap.py", 
line 2294, in pcolormesh
 ret = ax.pcolormesh(x,y,data,**kwargs)
 File "/Users/jsw/lib/python/matplotlib/axes.py", line 4836, in pcolormesh
 self.add_collection(collection)
 File "/Users/jsw/lib/python/matplotlib/axes.py", line 1140, in 
add_collection
 if len(collection._paths):
TypeError: object of type 'NoneType' has no len()
changing
if len(collection._paths):
to
if collection._paths and len(collection._paths)
in axes.py seems to fix it.
-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

That's great! I just assumed I had trampled over all kinds of 
semi-public APIs... ;)
Cheers,
Mike
Jeff Whitaker wrote:
> Michael Droettboom wrote:
>> Jeff Whitaker wrote:
>>> John Hunter wrote:
>>>> On Dec 3, 2007 2:08 PM, Jeff Whitaker <js...@fa...> wrote:
>>>>
>>>> 
>>>>> try:
>>>>> l,b,w,h = ax.get_position()
>>>>> except:
>>>>> l,b,w,h = (ax.get_position()).bounds
>>>>> 
>>>>
>>>> In general, blanket excepts are bad practice because they can mask
>>>> other bugs. You might catch the AttributeError, or do something like:
>>>>
>>>> pos = ax.get_position()
>>>> l, b, w, h = getattr(pos, 'bounds', pos)
>>>>
>>>> or maybe a version or other check to see if you are on the branch
>>>>
>>>> JDH
>>>> 
>>> John: You're right, I should do that. This is only in the examples, 
>>> not in the basemap code itself though.
>>
>> Just out of curiosity -- were there significant changes to the basemap 
>> code itself?
> 
> No, none. I did uncover one bug though!
> 
> -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:
>> John Hunter wrote:
>>> On Dec 3, 2007 2:08 PM, Jeff Whitaker <js...@fa...> wrote:
>>>
>>> 
>>>> try:
>>>> l,b,w,h = ax.get_position()
>>>> except:
>>>> l,b,w,h = (ax.get_position()).bounds
>>>> 
>>>
>>> In general, blanket excepts are bad practice because they can mask
>>> other bugs. You might catch the AttributeError, or do something like:
>>>
>>> pos = ax.get_position()
>>> l, b, w, h = getattr(pos, 'bounds', pos)
>>>
>>> or maybe a version or other check to see if you are on the branch
>>>
>>> JDH
>>> 
>> John: You're right, I should do that. This is only in the examples, 
>> not in the basemap code itself though.
>
> Just out of curiosity -- were there significant changes to the basemap 
> code itself?
No, none. I did uncover one bug though!
-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:
> John Hunter wrote:
>> On Dec 3, 2007 2:08 PM, Jeff Whitaker <js...@fa...> wrote:
>>
>> 
>>> try:
>>> l,b,w,h = ax.get_position()
>>> except:
>>> l,b,w,h = (ax.get_position()).bounds
>>> 
>>
>> In general, blanket excepts are bad practice because they can mask
>> other bugs. You might catch the AttributeError, or do something like:
>>
>> pos = ax.get_position()
>> l, b, w, h = getattr(pos, 'bounds', pos)
>>
>> or maybe a version or other check to see if you are on the branch
>>
>> JDH
>> 
> John: You're right, I should do that. This is only in the examples, not 
> in the basemap code itself though.
Just out of curiosity -- were there significant changes to the basemap 
code itself?
Glad to hear things are working with basemap. That was a lot faster 
than I expected. I feel much better about moving the transforms changes 
to the trunk...
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On Dec 3, 2007 1:15 PM, Eric Firing <ef...@ha...> wrote:
> 
>> Just a question: how do you handle taxes? Won't you be stuck paying
>> income tax on any donations? Not that I know of any way to get around
>> it short of incorporating as a nonprofit.
> 
> That is a good question -- does a donation not count as a gift? I
> think gifts under 10,000 are tax free.
> 
> JDH
It looks like you are right, based on a quick googling; at least 
individual-to-individual gifts are not reportable as income. It also 
makes sense; otherwise all the little donation funds that arise to help 
people under special circumstances would not work.
Eric

John Hunter wrote:
> On Dec 3, 2007 2:08 PM, Jeff Whitaker <js...@fa...> wrote:
>
> 
>> try:
>> l,b,w,h = ax.get_position()
>> except:
>> l,b,w,h = (ax.get_position()).bounds
>> 
>
> In general, blanket excepts are bad practice because they can mask
> other bugs. You might catch the AttributeError, or do something like:
>
> pos = ax.get_position()
> l, b, w, h = getattr(pos, 'bounds', pos)
>
> or maybe a version or other check to see if you are on the branch
>
> JDH
> 
John: You're right, I should do that. This is only in the examples, not 
in the basemap code itself though.
-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 Dec 3, 2007 2:08 PM, Jeff Whitaker <js...@fa...> wrote:
> try:
> l,b,w,h = ax.get_position()
> except:
> l,b,w,h = (ax.get_position()).bounds
In general, blanket excepts are bad practice because they can mask
other bugs. You might catch the AttributeError, or do something like:
pos = ax.get_position()
l, b, w, h = getattr(pos, 'bounds', pos)
or maybe a version or other check to see if you are on the branch
JDH

Michael Droettboom wrote:
> The transforms branch has seen very little outside of the matplotlib 
> examples, so it's good to find all of these error cases. Fixed in r4569.
>
> Cheers,
> Mike
>
>> Michael: And one more - contourf will die if you there are no 
>> contours at the requested levels. The error message looks like this:
>>
>> Traceback (most recent call last):
>> File "plotprecip.py", line 52, in <module>
>> cs = m.contourf(x,y,data,clevs,cmap=cm.s3pcpn)
>> File "/Users/jsw/lib/python/matplotlib/toolkits/basemap/basemap.py", 
>> line 2425, in contourf
>> CS = ax.contourf(x,y,data,*args,**kwargs)
>> File "/Users/jsw/lib/python/matplotlib/axes.py", line 5017, in contourf
>> return mcontour.ContourSet(self, *args, **kwargs)
>> File "/Users/jsw/lib/python/matplotlib/contour.py", line 460, in 
>> __init__
>> self.ax.add_collection(col)
>> File "/Users/jsw/lib/python/matplotlib/axes.py", line 1140, in 
>> add_collection
>> self.update_datalim(collection.get_datalim(self.transData))
>> File "/Users/jsw/lib/python/matplotlib/collections.py", line 142, in 
>> get_datalim
>> offsets, transOffset.frozen())
>> File "/Users/jsw/lib/python/matplotlib/path.py", line 481, in 
>> get_path_collection_extents
>> raise ValueError("No paths provided")
>>
>> To trigger this, try running the plotprecip.py basemap example.
>>
>> -Jeff
>>
>
Thanks Mike - all of the basemap examples are now working as expected 
with the transforms branch. The only significant change I had to make 
was to wrap axes.get_position in a try/except block, i.e.
try:
 l,b,w,h = ax.get_position()
except:
 l,b,w,h = (ax.get_position()).bounds
so that they would work both with the trunk and the 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

On Dec 3, 2007 1:52 PM, Christopher Barker <Chr...@no...> wrote:
> >>short of incorporating as a nonprofit.
>
> That's sure a lot of work -- can the PSA host this sort of thing? It
> would be a whole lot easier to use an existing organization.
Well, noone is proposing setting up an organization, just using sf's
existing donation infrastructure.
I found this on the question of whether the donations are taxable income:
http://taxprof.typepad.com/taxprof_blog/2005/02/tax_treatment_o_1.html
and some more info here
http://www.lclark.edu/~bojack/taxf04xans2.htm
It's not an issue I am too concerned about, really. In the unlikely
but pleasant event the donations are substantial, I think the costs of
the sprint or other uses of the donations for development could be
deducted as "expenses for the production of income", eg as in this
hypothetical example from the 2nd link:
Joe also has a blog and would want to know whether he can deduct the
160ドル he spends on the ISP payment and the (40ドル per month multiplied by
12) 480ドル he spends on his Internet costs. He would also want to know
whether he has to report the donations of 150ドル. The issue is whether
this is a hobby or a profit-oriented activity. IRC 183(c) defines an
activity not engaged in for profit as any activity other than one with
respect to which deductions are allowable under IRC 162 (the "ordinary
and necessary" business expenses) or under IRC 212 (expenses related
to the production of income. There is also a rebuttable presumption
in IRC 183(d) that an activity is engaged in for profit if, in three
or more of five consecutive years, the activity earns a profit. IRC
212 allows for a deduction of expenses for the production of income.
Since 20% of the time Joe spends on the Internet is related to his
blogging activity, he will be allowed to deduct 20% of the 480,ドル which
is a deduction of 96ドル. The 96ドル for his Internet service the 120ドル he
pays his ISP total to costs of 216ドル. Since the 216ドル exceed the
donations of 150ドル (which will be includable in gross income since they
are online tips and thus includable in gross income, Reg. 1.61-2(a)(1)
and the point in Olk v. US that if it isn't given with detached and
disinterested generosity but is, instead, for some service, which is
what these donations are) then Joe will have a loss of 66ドル.

On Dec 3, 2007 12:12 PM, Michael Droettboom <md...@st...> wrote:
> Works on RHEL4, with most applicable things built from source... Python
> 2.5, Gtk+: gtk+: 2.10.9, glib: 2.12.9, pygtk: 2.10.4, pygobject: 2.13.1
All OK here too, SVN build of numpy/matplotlib, ubuntu Feisty standard
packages of everything else:
In [6]: gtk.gtk_version
Out[6]: (2, 10, 11)
In [7]: gtk.pygtk_version
Out[7]: (2, 10, 4)
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
Cheers,
f

>>short of incorporating as a nonprofit.
That's sure a lot of work -- can the PSA host this sort of thing? It 
would be a whole lot easier to use an existing organization.
-CHB
-- 
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...

On Dec 3, 2007 1:15 PM, Eric Firing <ef...@ha...> wrote:
> Just a question: how do you handle taxes? Won't you be stuck paying
> income tax on any donations? Not that I know of any way to get around
> it short of incorporating as a nonprofit.
That is a good question -- does a donation not count as a gift? I
think gifts under 10,000 are tax free.
JDH

The transforms branch has seen very little outside of the matplotlib 
examples, so it's good to find all of these error cases. Fixed in r4569.
Cheers,
Mike
> Michael: And one more - contourf will die if you there are no contours 
> at the requested levels. The error message looks like this:
> 
> Traceback (most recent call last):
> File "plotprecip.py", line 52, in <module>
> cs = m.contourf(x,y,data,clevs,cmap=cm.s3pcpn)
> File "/Users/jsw/lib/python/matplotlib/toolkits/basemap/basemap.py", 
> line 2425, in contourf
> CS = ax.contourf(x,y,data,*args,**kwargs)
> File "/Users/jsw/lib/python/matplotlib/axes.py", line 5017, in contourf
> return mcontour.ContourSet(self, *args, **kwargs)
> File "/Users/jsw/lib/python/matplotlib/contour.py", line 460, in __init__
> self.ax.add_collection(col)
> File "/Users/jsw/lib/python/matplotlib/axes.py", line 1140, in 
> add_collection
> self.update_datalim(collection.get_datalim(self.transData))
> File "/Users/jsw/lib/python/matplotlib/collections.py", line 142, in 
> get_datalim
> offsets, transOffset.frozen())
> File "/Users/jsw/lib/python/matplotlib/path.py", line 481, in 
> get_path_collection_extents
> raise ValueError("No paths provided")
> 
> To trigger this, try running the plotprecip.py basemap example.
> 
> -Jeff
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Works on RHEL4, with most applicable things built from source... Python 
2.5, Gtk+: gtk+: 2.10.9, glib: 2.12.9, pygtk: 2.10.4, pygobject: 2.13.1
Cheers,
Mike
Jeff Whitaker wrote:
> John Hunter wrote:
>> I just noticed that the blit API in GTK* is causing a seg fault on my
>> desktop. Can anyone confirm this on another system. Has anyone made
>> any changes that you are aware of that might have affected this part
>> of the code? I am seeing problems with
>> examples/animation_blit.py and examples/poly_editor.py so it looks
>> like anything using the copy region / blit API in GTK is broken, at
>> least on my system. tkagg is working fine, so it is probably not a
>> problem on the agg side, and GTK and GTKAgg are both affected. I
>> don't use this functionality often, so I don't know how long the
>> problem has persisted. In fact, it is possible I have never tested it
>> on this system (solaris x86 with pygtk 2.6)
>>
>> JDH
>>
>> 
> 
> John: Works fine on OS X with
> 
> Gtk+: gtk+: 2.6.10, glib: 2.12.4, pygtk: 2.6.3, pygobject [pre-pygobject]
> 
> -Jeff
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> To enable donations, all project admins must opt in. In addition to
> me, those are Charlie, Darren, Eric, Jeff and Michael and the opt in
> page is at
> http://sourceforge.net/project/admin/donations.php?group_id=80706.
> The donations are set up to go into my paypal account, but if one of
> you wants to create a dedicated account to handle these, that is fine
> by me.
I seem to be having some trouble with sourceforge; it is not clear 
whether my update is going through. If we don't get a confirming email 
 I will try again later.
> 
> If anyone has concerns or suggestions, let me know. We get a fair
> amount of web traffic and maybe we can raise enough money to do
> something useful. I have no experience with donations so I have no
> idea whether this is feasible, but it seems like it is worth a shot.
Just a question: how do you handle taxes? Won't you be stuck paying 
income tax on any donations? Not that I know of any way to get around 
it short of incorporating as a nonprofit.
Eric

It seems to have broken when I upgraded the branch to Agg 2.4. Agg 2.4 
now handles interpolating the edges of the image with a background color 
more-or-less "correctly", and no longer needs the hack that adds 
boundary pixels to the image before sending it to Agg for interpolation. 
 Should also be much faster with large images. Fixed in r4568.
Cheers,
Mike
Jeff Whitaker wrote:
> Michael Droettboom wrote:
>> Thanks for finding this. It was an x,y reversal indexing the mesh 
>> array. Fixed in r4565.
>>
>> Cheers,
>> Mike
>>
>> Jeff Whitaker wrote:
>>>
>>> Hi Michael: I've been testing basemap with the transforms branch. 
>>> All the examples now run, but the ones that use pcolormesh don't work 
>>> correctly. I've attached an example. In the trunk, using either 
>>> pcolor or pcolormesh produce an identical plot. In the transforms 
>>> branch, using pcolor produces the correct plot, but using pcolormesh 
>>> seems to scramble the image.
>>>
>>> -Jeff
>>>
>>
> OK - since you fixed that one so fast, here's another one! Seems like 
> images don't quite fill up the entire axes - running this script with 
> the transforms branch you'll see a white strip around the top and right 
> side of the image.
> 
> -Jeff
> 
> P.S. the data this script needs is in the basemap examples directory.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> I just noticed that the blit API in GTK* is causing a seg fault on my
> desktop. Can anyone confirm this on another system. Has anyone made
> any changes that you are aware of that might have affected this part
> of the code? I am seeing problems with
> examples/animation_blit.py and examples/poly_editor.py so it looks
> like anything using the copy region / blit API in GTK is broken, at
> least on my system. tkagg is working fine, so it is probably not a
> problem on the agg side, and GTK and GTKAgg are both affected. I
> don't use this functionality often, so I don't know how long the
> problem has persisted. In fact, it is possible I have never tested it
> on this system (solaris x86 with pygtk 2.6)
>
> JDH
>
> 
John: Works fine on OS X with
Gtk+: gtk+: 2.6.10, glib: 2.12.4, pygtk: 2.6.3, pygobject [pre-pygobject]
-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