matplotlib-devel Mailing List for matplotlib

Hi Eric,
On Sun, Jan 29, 2012 at 1:35 PM, Eric Firing <ef...@ha...> wrote:
> Yes, this became evident right away after the transition; in addition,
> there was a coordination glitch such that quite a few bugs that I had
> closed on SF, trying to clear out some junk before the transition, ended
> up getting resurrected on github, complete with dead links.
Got it, I missed that previous discussion.
> This is a triage situation; we have to consider the cost/benefit
> tradeoff of various ways of dealing with the mess, and with the glut of
> bug and other reports. The fact is that we were way behind in dealing
> with the SF bugs, and we are falling behind in dealing with github bugs.
>
> I think the best approach is to be fairly brutal in closing bug reports.
> We don't have the developer time to deal with very many. Those that
> accumulate faster than we can deal with them merely cost us time
> whenever one of us scans the set of reports in an attempt to get the
> list under control by finding ways to close a few.
It's unfortunate that github doesn't offer a 'priority' field so that
one can threshold on it. We use 'prio-X' labels with X in {low,
medium, high, blocker} as a substitute, but there's no way to see 'all
with prioirty >= high', for example.
But we've been trying to aggressively label everything with a
priority, and in practice only high/blocker ones really get worked on,
unless someone external shows up with a pull request for anything
below that.
My take right now is that even bugs are almost all lower priority than
pull requests: if someone took the time to actually contribute code, I
think it's critically important to get back to them with feedback.
Not having a timely review and response to a PR is the best way to
discourage potential new contributors. My hope is that by being
pretty aggressive on that, we'll grow our developer pool enough to be
able to make some headway into the bug backlog. One can dream... :)
> So, the dead SF links are the least of our problems; not that big a
> deal. We would lose little by simply closing all of the transfered
> reports; or at least closing all of those older than some threshold.
You're probably right, though I sort of prefer to keep an open bug if
the problem really isn't resolved. But marking all SF bugs with
priority low (if you decide to create a similar set of priority
labels) would at least indicate this intent, and let you focus only on
the real problems more easily. Because actually closing them raises
the risk that they will get re-reported, and then it's even more work
to start linking bugs or closing dupes.
Ultimately though, we're all (mpl, ipython, scipy, etc) suffering from
the same problem: despite the enormous growth in the user base of the
scientific python tools in the last few years, the developer pool has
not really grown at the same rate. Our projects are have dangerously
small core teams. I wish I knew how to change this...
Cheers,
f

On 01/29/2012 10:53 AM, Fernando Perez wrote:
> Hi all,
>
> I don't know if you guys were aware of this, and if there's anything
> that can be done, but I just realized that all the bugs tagged SF:
Fernando,
Yes, this became evident right away after the transition; in addition, 
there was a coordination glitch such that quite a few bugs that I had 
closed on SF, trying to clear out some junk before the transition, ended 
up getting resurrected on github, complete with dead links.
This is a triage situation; we have to consider the cost/benefit 
tradeoff of various ways of dealing with the mess, and with the glut of 
bug and other reports. The fact is that we were way behind in dealing 
with the SF bugs, and we are falling behind in dealing with github bugs.
I think the best approach is to be fairly brutal in closing bug reports. 
 We don't have the developer time to deal with very many. Those that 
accumulate faster than we can deal with them merely cost us time 
whenever one of us scans the set of reports in an attempt to get the 
list under control by finding ways to close a few.
So, the dead SF links are the least of our problems; not that big a 
deal. We would lose little by simply closing all of the transfered 
reports; or at least closing all of those older than some threshold.
Eric
>
> https://github.com/matplotlib/matplotlib/issues?labels=SF&sort=created&direction=desc&state=open&page=1
>
> have useless links to their SF original pages, b/c SF has completely
> closed access to the old tracker, e.g.:
>
> http://sourceforge.net/tracker/?func=detail&aid=3044267&group_id=80706&atid=560723
>
> I don't know if in the migration, the github issue has all the
> information that was in the old bug. In ipython when we migrated from
> launchpad we kept links to the old issues as well:
>
> https://github.com/ipython/ipython/issues/13 ==>
> https://bugs.launchpad.net/ipython/+bug/508971
>
> but fortunately launchpad continues to show the original bug in full.
> This is useful for a number of reasons. Launchpad is nice enough to
> let you disable the bug tracker for new bug submissions while leaving
> all existing bug pages still available. This is much more sensible
> than what SF seems to be doing.
>
> I don't know there's much we can do, since this is really a
> SourceForge issue. But I wanted to mention it at least; if there's
> important information buried in there, it might be possible to reopen
> the SF tracker temporarily, scrape the bug pages for everything and
> close it again. I just don't know if the orignal bug transfer process
> managed to move everything or not...
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just 99ドル.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi all,
I don't know if you guys were aware of this, and if there's anything
that can be done, but I just realized that all the bugs tagged SF:
https://github.com/matplotlib/matplotlib/issues?labels=SF&sort=created&direction=desc&state=open&page=1
have useless links to their SF original pages, b/c SF has completely
closed access to the old tracker, e.g.:
http://sourceforge.net/tracker/?func=detail&aid=3044267&group_id=80706&atid=560723
I don't know if in the migration, the github issue has all the
information that was in the old bug. In ipython when we migrated from
launchpad we kept links to the old issues as well:
https://github.com/ipython/ipython/issues/13 ==>
https://bugs.launchpad.net/ipython/+bug/508971
but fortunately launchpad continues to show the original bug in full.
This is useful for a number of reasons. Launchpad is nice enough to
let you disable the bug tracker for new bug submissions while leaving
all existing bug pages still available. This is much more sensible
than what SF seems to be doing.
I don't know there's much we can do, since this is really a
SourceForge issue. But I wanted to mention it at least; if there's
important information buried in there, it might be possible to reopen
the SF tracker temporarily, scrape the bug pages for everything and
close it again. I just don't know if the orignal bug transfer process
managed to move everything or not...
Cheers,
f

On Sun, Jan 29, 2012 at 12:26 PM, Jeff Whitaker <js...@fa...> wrote:
> From matplotlib's perspective, the lat/lon labels in Basemap are
> randomly located text objects - so it's not likely to ever work for
> Basemap plots unless matplotlib takes into account all the artist
> objects associated with a figure.
Ah, OK. That's good to know, because then it means that the automatic
use of 'tight' we make in ipython is probably over-aggressive then.
I'll add your note above to the bug report, and we'll think how to
best deal with it in ipython then.
Cheers,
f

On 1/29/12 11:30 AM, Fernando Perez wrote:
> On Sun, Jan 29, 2012 at 10:22 AM, Nathaniel Smith<nj...@po...> wrote:
>>> Not a bug. There are only so many artist objects we assume for determining the tight bbox. Suptitle is not one of them.
>> Why is this the desired behavior?
> I was just going to ask the same. And as Jeff Whitaker points out,
> all x and y (longitude/latitude) labels also get clipped.
>
> I can understand not considering the position of arbitrarily laid out
> text that a user could have put in a random location.
 From matplotlib's perspective, the lat/lon labels in Basemap are 
randomly located text objects - so it's not likely to ever work for 
Basemap plots unless matplotlib takes into account all the artist 
objects associated with a figure.
-Jeff
> But clipping
> something that is provided by a standard api call, such as a figure
> title, does seem much more like a bug than a feature to me, I'm afraid.
>
> Cheers,
>
> f

On Sun, Jan 29, 2012 at 11:25 AM, Benjamin Root <ben...@ou...> wrote:
> I certainly have no objections. Most likely it was an oversight.
OK, thanks. Filed so at least there's a record of it:
https://github.com/matplotlib/matplotlib/issues/688
We'll find a workaround in ipython in the meantime.
Cheers,
f

On Sunday, January 29, 2012, Fernando Perez <fpe...@gm...> wrote:
> On Sun, Jan 29, 2012 at 10:22 AM, Nathaniel Smith <nj...@po...> wrote:
>>> Not a bug. There are only so many artist objects we assume for
determining the tight bbox. Suptitle is not one of them.
>>
>> Why is this the desired behavior?
>
> I was just going to ask the same. And as Jeff Whitaker points out,
> all x and y (longitude/latitude) labels also get clipped.
>
> I can understand not considering the position of arbitrarily laid out
> text that a user could have put in a random location. But clipping
> something that is provided by a standard api call, such as a figure
> title, does seem much more like a bug than a feature to me, I'm afraid.
>
> Cheers,
>
> f
>
I certainly have no objections. Most likely it was an oversight.
Ben Root

On Sun, Jan 29, 2012 at 10:30 AM, Fernando Perez <fpe...@gm...> wrote:
> And as Jeff Whitaker points out,
> all x and y (longitude/latitude) labels also get clipped.
I meant to put at the end of that sentence: "in the basemap example".
The simple plot has no clipping issues with labels, only with the
suptitle.
Cheers,
f

On Sun, Jan 29, 2012 at 7:42 AM, Benjamin Root <ben...@ou...> wrote:
> Not a bug. There are only so many artist objects we assume for determining the tight bbox. Suptitle is not one of them.
Why is this the desired behavior?
-- Nathaniel

On Sun, Jan 29, 2012 at 10:22 AM, Nathaniel Smith <nj...@po...> wrote:
>> Not a bug. There are only so many artist objects we assume for determining the tight bbox. Suptitle is not one of them.
>
> Why is this the desired behavior?
I was just going to ask the same. And as Jeff Whitaker points out,
all x and y (longitude/latitude) labels also get clipped.
I can understand not considering the position of arbitrarily laid out
text that a user could have put in a random location. But clipping
something that is provided by a standard api call, such as a figure
title, does seem much more like a bug than a feature to me, I'm afraid.
Cheers,
f

On 1/29/12 8:42 AM, Benjamin Root wrote:
>
>
> On Sunday, January 29, 2012, Fernando Perez <fpe...@gm... 
> <mailto:fpe...@gm...>> wrote:
> > Hi all,
> >
> > in ipython for the qtconsole and notebook, we send inline figures using
> >
> > fig.canvas.print_figure(bytes_io, format=fmt, bbox_inches='tight')
> >
> > as seen here:
> >
> > 
> https://github.com/ipython/ipython/blob/master/IPython/core/pylabtools.py#L104
> >
> > However, this produces truncated figure titles. Consider this code:
> >
> > f, ax = plt.subplots()
> > ax.plot(rand(100))
> > ax.set_title('Axis title')
> > f.suptitle('Figure title');
> >
> > ###
> >
> > which produces this in the notebook:
> >
> > http://img546.imageshack.us/img546/5448/selection001c.png
> >
> > As you can see, the figure title gets truncated.
> >
> > We started using bbox_inches='tight' because otherwise in many cases
> > the images were coming back with insane amounts of white padding, and
> > Stefan vdW suggested this fix. But it seems that in other cases it
> > actually loses data, which is even worse...
> >
> > A slightly more complicated example, using basemap, not only truncates
> > the title but also all the x and y labels:
> >
> > from mpl_toolkits.basemap import Basemap
> >
> > lon0, lat0, lon1, lat1 = (84.38, 26.22, 88.9, 29.8)
> > resolution = 'i'
> >
> > parallels = np.linspace(lat0, lat1, 5)
> > meridians = np.linspace(lon0, lon1, 5)
> >
> > f, ax = plt.subplots()
> > m = Basemap(lon0, lat0, lon1, lat1, resolution=resolution, ax=ax)
> > m.drawcountries(color=(1,1,0)) # country boundaries in pure yellow
> > m.drawrivers(color=(0,1,1)) # rivers in cyan
> > m.bluemarble() # NASA bluemarble image
> > m.drawmeridians(meridians, labels=[0,0,0,1], fmt='%.2f')
> > m.drawparallels(parallels, labels=[1,0,0,0], fmt='%.2f')
> > f.suptitle('The Himalayas');
> >
> > #####
> >
> > produces:
> >
> > http://img192.imageshack.us/img192/986/selection002e.png
> >
> >
> > This looks like a matplotlib bug, but I have no idea how easy it is to
> > fix. In the meantime, should we in ipython just revert back to not
> > using bbox_inches, or is there an alternative?
> >
> > Thanks!
> >
> > f
> >
>
> Not a bug. There are only so many artist objects we assume for 
> determining the tight bbox. Suptitle is not one of them. However, If 
> you collect all of the artists that you want considered, you can pass 
> in a list of them to bbox_artists (IIRC) to have them considered as well.
>
> Now, with respect to the Basemap example, there might be a bug there, 
> but it can still be worked around by passing in the list of labels to 
> the kwarg.
>
> Cheers!
> Ben Root
The lat and lon labels in Basemap are axes.text objects, which 
apparently are not considered when computing the bbox either.
-Jeff

On Sunday, January 29, 2012, Fernando Perez <fpe...@gm...> wrote:
> Hi all,
>
> in ipython for the qtconsole and notebook, we send inline figures using
>
> fig.canvas.print_figure(bytes_io, format=fmt, bbox_inches='tight')
>
> as seen here:
>
>
https://github.com/ipython/ipython/blob/master/IPython/core/pylabtools.py#L104
>
> However, this produces truncated figure titles. Consider this code:
>
> f, ax = plt.subplots()
> ax.plot(rand(100))
> ax.set_title('Axis title')
> f.suptitle('Figure title');
>
> ###
>
> which produces this in the notebook:
>
> http://img546.imageshack.us/img546/5448/selection001c.png
>
> As you can see, the figure title gets truncated.
>
> We started using bbox_inches='tight' because otherwise in many cases
> the images were coming back with insane amounts of white padding, and
> Stefan vdW suggested this fix. But it seems that in other cases it
> actually loses data, which is even worse...
>
> A slightly more complicated example, using basemap, not only truncates
> the title but also all the x and y labels:
>
> from mpl_toolkits.basemap import Basemap
>
> lon0, lat0, lon1, lat1 = (84.38, 26.22, 88.9, 29.8)
> resolution = 'i'
>
> parallels = np.linspace(lat0, lat1, 5)
> meridians = np.linspace(lon0, lon1, 5)
>
> f, ax = plt.subplots()
> m = Basemap(lon0, lat0, lon1, lat1, resolution=resolution, ax=ax)
> m.drawcountries(color=(1,1,0)) # country boundaries in pure yellow
> m.drawrivers(color=(0,1,1)) # rivers in cyan
> m.bluemarble() # NASA bluemarble image
> m.drawmeridians(meridians, labels=[0,0,0,1], fmt='%.2f')
> m.drawparallels(parallels, labels=[1,0,0,0], fmt='%.2f')
> f.suptitle('The Himalayas');
>
> #####
>
> produces:
>
> http://img192.imageshack.us/img192/986/selection002e.png
>
>
> This looks like a matplotlib bug, but I have no idea how easy it is to
> fix. In the meantime, should we in ipython just revert back to not
> using bbox_inches, or is there an alternative?
>
> Thanks!
>
> f
>
Not a bug. There are only so many artist objects we assume for determining
the tight bbox. Suptitle is not one of them. However, If you collect all
of the artists that you want considered, you can pass in a list of them to
bbox_artists (IIRC) to have them considered as well.
Now, with respect to the Basemap example, there might be a bug there, but
it can still be worked around by passing in the list of labels to the kwarg.
Cheers!
Ben Root

Hi all,
in ipython for the qtconsole and notebook, we send inline figures using
fig.canvas.print_figure(bytes_io, format=fmt, bbox_inches='tight')
as seen here:
https://github.com/ipython/ipython/blob/master/IPython/core/pylabtools.py#L104
However, this produces truncated figure titles. Consider this code:
f, ax = plt.subplots()
ax.plot(rand(100))
ax.set_title('Axis title')
f.suptitle('Figure title');
###
which produces this in the notebook:
http://img546.imageshack.us/img546/5448/selection001c.png
As you can see, the figure title gets truncated.
We started using bbox_inches='tight' because otherwise in many cases
the images were coming back with insane amounts of white padding, and
Stefan vdW suggested this fix. But it seems that in other cases it
actually loses data, which is even worse...
A slightly more complicated example, using basemap, not only truncates
the title but also all the x and y labels:
from mpl_toolkits.basemap import Basemap
lon0, lat0, lon1, lat1 = (84.38, 26.22, 88.9, 29.8)
resolution = 'i'
parallels = np.linspace(lat0, lat1, 5)
meridians = np.linspace(lon0, lon1, 5)
f, ax = plt.subplots()
m = Basemap(lon0, lat0, lon1, lat1, resolution=resolution, ax=ax)
m.drawcountries(color=(1,1,0)) # country boundaries in pure yellow
m.drawrivers(color=(0,1,1)) # rivers in cyan
m.bluemarble() # NASA bluemarble image
m.drawmeridians(meridians, labels=[0,0,0,1], fmt='%.2f')
m.drawparallels(parallels, labels=[1,0,0,0], fmt='%.2f')
f.suptitle('The Himalayas');
#####
produces:
http://img192.imageshack.us/img192/986/selection002e.png
This looks like a matplotlib bug, but I have no idea how easy it is to
fix. In the meantime, should we in ipython just revert back to not
using bbox_inches, or is there an alternative?
Thanks!
f