matplotlib-devel Mailing List for matplotlib

Please see if this PR works.

https://github.com/matplotlib/matplotlib/pull/689

Regards,

-JJ

On Mon, Jan 30, 2012 at 1:03 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Mon, Jan 30, 2012 at 5:26 AM, Jeff Whitaker <js...@fa...> wrote:
>> unless matplotlib takes into account all the artist
>> objects associated with a figure.
>
> My primary reason behind not accounting all the artists was that, in
> general, Matplotlib does not know the exact bounding box of artists
> when the artists are clipped.
>
> In the current implementation, axes title, axis labels and ticklabels
> are only accounted, and we have an optional parameter of
> *bbox_extra_artists* so that users can manually change this behavior.
>
> By the way, for now, I'm more inclined to change the behavior to
> account all the texts artists (at least), although we may see white
> space sometimes.
>
> Regards,
>
> -JJ

On Mon, Jan 30, 2012 at 5:26 AM, Jeff Whitaker <js...@fa...> wrote:
> unless matplotlib takes into account all the artist
> objects associated with a figure.

My primary reason behind not accounting all the artists was that, in
general, Matplotlib does not know the exact bounding box of artists
when the artists are clipped.

In the current implementation, axes title, axis labels and ticklabels
are only accounted, and we have an optional parameter of
*bbox_extra_artists* so that users can manually change this behavior.

By the way, for now, I'm more inclined to change the behavior to
account all the texts artists (at least), although we may see white
space sometimes.

Regards,

-JJ

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

On Wed, Jan 25, 2012 at 7:14 AM, andi <and...@go...> wrote:

>  Hi Tony,
>
> thanks for your reply! I am not using the pdf backend, but the GTKAgg
> backend. Is it working with this backend in the development version?
>
> Cheers
> Andi
>

Hi Andi,

Unfortunately, I can't run the GTKAgg backend, but I checked your code
snippet on the backends I have on my system. It seems this behavior is
really inconsistent:

Works:
* agg
* qt4agg
* tkagg

Doesn't work:
* pdf
* macosx

To be honest, I don't understand the magical workings of the backends very
well. I've copied the developer list since the consistency of backends
seems like a relevant issue.

-Tony

P.S. Andi: Be sure to "reply all" since the mailing list doesn't
automatically do this for some reason.


>
> On 25/01/12 00:26, Tony Yu wrote:
>
>
>
> On Tue, Jan 24, 2012 at 12:53 PM, andi <and...@go...> wrote:
>
>> Hi all,
>>
>> I have some old custom code for generating videos from matplotlib (not
>> using the animation module). It used to work, but is now failing.
>> Here is what I am doing:
>>
>> -------------------
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>> fig = plt.figure()
>> ax = fig.add_subplot(111)
>> im = ax.imshow(np.zeros((100, 100)))
>> fig.canvas.draw()
>> ax.draw_artist(im)
>> ------------------
>>
>> ... and draw_artist from axes.py then gives me an AssertionError because
>> no renderer is found (assert self._cachedRenderer is not None).
>>
>> Right now I am using matplotlib 1.0.1 and I think that the above used to
>> work with older versions in matplotlib. See e.g.
>>
>> http://www.mail-archive.com/mat...@li.../msg06598.html
>>
>> Any ideas?
>>
>> Cheers
>> Andi
>>
>>
> Hi Andi,
>
> I'm running a development version of matplotlib, and your code runs
> without issue. That doesn't really solve your issue, but it means that it's
> not due to deprecation.
>
> On a hunch, I tried running the code with
> >>> import matplotlib
> >>> matplotlib.use('pdf')
> at the top of the file, and I got the same error. Not really sure why,
> though. Do you happen to have the pdf backend set as the default?
>
> -Tony
>
>

On Tue, Jan 24, 2012 at 10:12 AM, Tony Yu <ts...@gm...> wrote:

>
>
> On Sun, Jan 22, 2012 at 5:58 PM, Joe Kington <jki...@ge...>wrote:
>
>> I've recently been playing around with a widget intended to be similar to
>> matlab's "data cursor".
>>
>> Would this be useful for inclusion into matplotlib.widgets?
>>
>> https://gist.github.com/1659108
>>
>> At the moment, it doesn't inherit from the base Widget class, but that's
>> easily changed.
>>
>> On the other hand, it doesn't fit the model of the rest of the widgets in
>> that it takes a sequence (or single) artist, instead of an axes instance.
>>
>> If folks think it would be useful, I can submit a pull request.
>>
>> Thanks,
>> -Joe
>>
>
> This is pretty cool. Any idea how much work it would take to add handling
> of images?
>
> -Tony
>

Just to clarify: by "handling images", I mean displaying the intensity
value at a point (it currently just displays the x, y coordinates).

-Tony

On Sun, Jan 22, 2012 at 5:58 PM, Joe Kington <jki...@ge...>wrote:

> I've recently been playing around with a widget intended to be similar to
> matlab's "data cursor".
>
> Would this be useful for inclusion into matplotlib.widgets?
>
> https://gist.github.com/1659108
>
> At the moment, it doesn't inherit from the base Widget class, but that's
> easily changed.
>
> On the other hand, it doesn't fit the model of the rest of the widgets in
> that it takes a sequence (or single) artist, instead of an axes instance.
>
> If folks think it would be useful, I can submit a pull request.
>
> Thanks,
> -Joe
>

This is pretty cool. Any idea how much work it would take to add handling
of images?

-Tony

I've recently been playing around with a widget intended to be similar to
matlab's "data cursor".

Would this be useful for inclusion into matplotlib.widgets?

https://gist.github.com/1659108

At the moment, it doesn't inherit from the base Widget class, but that's
easily changed.

On the other hand, it doesn't fit the model of the rest of the widgets in
that it takes a sequence (or single) artist, instead of an axes instance.

If folks think it would be useful, I can submit a pull request.

Thanks,
-Joe

Ah.  That explains why I couldn't reproduce it -- I didn't realize the 
issue had already been closed.

Mike

On 01/17/2012 12:53 PM, Eric Firing wrote:
> Mike,
>
> Git bisect showed that the problem was your merge commit bca1fb0; you
> were merging a changeset relative to a very old version, and I'm pretty
> sure that you accidentally kept the old version of a line.  I switched
> it back to the new version:
>
> https://github.com/matplotlib/matplotlib/commit/c9cefdcf50742fd041636b20aa48d3a821d3299d
>
> Maybe your suggested patch below is still a good idea, but I think that
> is now an independent question.
>
> Eric
>
>
> On 01/17/2012 05:37 AM, Michael Droettboom wrote:
>> I can't confirm this on RHEL5 64-bit or Fedora 16 64-bit.
>>
>> Have you tried removing the build and installed directories and
>> rebuilding from scratch?
>>
>> I'm shooting in the dark, but does the attached patch resolve your issue?
>>
>> diff --git a/src/_png.cpp b/src/_png.cpp
>> index 9437c87..c17dec9 100644
>> --- a/src/_png.cpp
>> +++ b/src/_png.cpp
>> @@ -553,7 +553,7 @@ _png_module::_read_png(const Py::Object&   py_fileobj,
>> const b
>>
>>         if (PyErr_Occurred()) {
>>             Py_DECREF((PyObject *)A);
>> -        return NULL;
>> +        throw Py::Exception();
>>         } else {
>>             return (PyObject *)A;
>>
>> Mike
>>
>> On 01/14/2012 04:51 PM, Eric Firing wrote:
>>> On 01/14/2012 09:02 AM, Benjamin Root wrote:
>>>> Tried using plt.imread() today on a PNG file, and I am getting this
>>>> PyCXX error:
>>>>
>>>> Traceback (most recent call last):
>>>>       File "<stdin>", line 1, in<module>
>>>>       File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
>>>> 1746, in imread
>>>>         return _imread(*args, **kwargs)
>>>>       File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
>>>> 1218, in imread
>>>>         return handler(fd)
>>>> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>>>>
>>>> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
>>>> happen to both color and b&w images.  scipy.ndimage.imread() still works
>>>> fine, though.
>>>>
>>>> Ben Root
>>> I get the same thing with master on 64-bit ubuntu natty, but not with
>>> v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two.
>>>      The most recent commit to that file is not causing the problem, but I
>>> have not tracked it down beyond that.
>>>
>>> Eric
>>>
>>> ------------------------------------------------------------------------------
>>> RSA(R) Conference 2012
>>> Mar 27 - Feb 2
>>> Save $400 by Jan. 27
>>> Register now!
>>> http://p.sf.net/sfu/rsa-sfdev2dev2
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> 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-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Mike,

Git bisect showed that the problem was your merge commit bca1fb0; you 
were merging a changeset relative to a very old version, and I'm pretty 
sure that you accidentally kept the old version of a line.  I switched 
it back to the new version:

https://github.com/matplotlib/matplotlib/commit/c9cefdcf50742fd041636b20aa48d3a821d3299d

Maybe your suggested patch below is still a good idea, but I think that 
is now an independent question.

Eric


On 01/17/2012 05:37 AM, Michael Droettboom wrote:
> I can't confirm this on RHEL5 64-bit or Fedora 16 64-bit.
>
> Have you tried removing the build and installed directories and
> rebuilding from scratch?
>
> I'm shooting in the dark, but does the attached patch resolve your issue?
>
> diff --git a/src/_png.cpp b/src/_png.cpp
> index 9437c87..c17dec9 100644
> --- a/src/_png.cpp
> +++ b/src/_png.cpp
> @@ -553,7 +553,7 @@ _png_module::_read_png(const Py::Object&  py_fileobj,
> const b
>
>        if (PyErr_Occurred()) {
>            Py_DECREF((PyObject *)A);
> -        return NULL;
> +        throw Py::Exception();
>        } else {
>            return (PyObject *)A;
>
> Mike
>
> On 01/14/2012 04:51 PM, Eric Firing wrote:
>> On 01/14/2012 09:02 AM, Benjamin Root wrote:
>>> Tried using plt.imread() today on a PNG file, and I am getting this
>>> PyCXX error:
>>>
>>> Traceback (most recent call last):
>>>      File "<stdin>", line 1, in<module>
>>>      File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
>>> 1746, in imread
>>>        return _imread(*args, **kwargs)
>>>      File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
>>> 1218, in imread
>>>        return handler(fd)
>>> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>>>
>>> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
>>> happen to both color and b&w images.  scipy.ndimage.imread() still works
>>> fine, though.
>>>
>>> Ben Root
>> I get the same thing with master on 64-bit ubuntu natty, but not with
>> v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two.
>>     The most recent commit to that file is not causing the problem, but I
>> have not tracked it down beyond that.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Mar 27 - Feb 2
>> Save $400 by Jan. 27
>> Register now!
>> http://p.sf.net/sfu/rsa-sfdev2dev2
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I can't confirm this on RHEL5 64-bit or Fedora 16 64-bit.

Have you tried removing the build and installed directories and 
rebuilding from scratch?

I'm shooting in the dark, but does the attached patch resolve your issue?

diff --git a/src/_png.cpp b/src/_png.cpp
index 9437c87..c17dec9 100644
--- a/src/_png.cpp
+++ b/src/_png.cpp
@@ -553,7 +553,7 @@ _png_module::_read_png(const Py::Object& py_fileobj, 
const b

      if (PyErr_Occurred()) {
          Py_DECREF((PyObject *)A);
-        return NULL;
+        throw Py::Exception();
      } else {
          return (PyObject *)A;

Mike

On 01/14/2012 04:51 PM, Eric Firing wrote:
> On 01/14/2012 09:02 AM, Benjamin Root wrote:
>> Tried using plt.imread() today on a PNG file, and I am getting this
>> PyCXX error:
>>
>> Traceback (most recent call last):
>>     File "<stdin>", line 1, in<module>
>>     File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
>> 1746, in imread
>>       return _imread(*args, **kwargs)
>>     File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
>> 1218, in imread
>>       return handler(fd)
>> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>>
>> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
>> happen to both color and b&w images.  scipy.ndimage.imread() still works
>> fine, though.
>>
>> Ben Root
> I get the same thing with master on 64-bit ubuntu natty, but not with
> v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two.
>    The most recent commit to that file is not causing the problem, but I
> have not tracked it down beyond that.
>
> Eric
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 01/14/2012 09:02 AM, Benjamin Root wrote:
> Tried using plt.imread() today on a PNG file, and I am getting this
> PyCXX error:
>
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line
> 1746, in imread
>      return _imread(*args, **kwargs)
>    File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line
> 1218, in imread
>      return handler(fd)
> TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)
>
> Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to
> happen to both color and b&w images.  scipy.ndimage.imread() still works
> fine, though.
>
> Ben Root

I get the same thing with master on 64-bit ubuntu natty, but not with 
v1.1.x.  Mike did quite a bit of work on src/_png.cpp between those two. 
  The most recent commit to that file is not causing the problem, but I 
have not tracked it down beyond that.

Eric

Tried using plt.imread() today on a PNG file, and I am getting this PyCXX
error:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ben/Programs/matplotlib/lib/matplotlib/pyplot.py", line 1746,
in imread
    return _imread(*args, **kwargs)
  File "/home/ben/Programs/matplotlib/lib/matplotlib/image.py", line 1218,
in imread
    return handler(fd)
TypeError: PyCXX: Error creating object of type N2Py6ObjectE from (nil)

Using master branch on Python 2.7 on 32-bit Ubuntu Oneric.  Seems to happen
to both color and b&w images.  scipy.ndimage.imread() still works fine,
though.

Ben Root

On Fri, Jan 13, 2012 at 6:32 PM, Gellule Xg <gel...@fr...> wrote:

> On 1/13/12 12:53 , Tony Yu wrote:
>
>>
>> On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg <gel...@fr...
>> <mailto:gel...@fr...>> wrote:
>>
>>    If you are a macosx backend user, you are welcomed to test the
>> following
>>    branch: https://github.com/gellule/**matplotlib<https://github.com/gellule/matplotlib>.
>> With the branch, when
>>    issuing a pylab.show() in non-interactive mode, the plot windows should
>>    appear in the foreground with focus, instead of appearing in the
>>    background. It should make things a little easier for you.
>>
>>
>> This works as advertised on my system (plot window grabs focus when
>> running scripts in MacVim, Terminal, and IPython when in non-interactive
>> mode). Unfortunately, I tend to use the QT4Agg backend, which also
>> leaves plot windows in the background. Maybe I'd switch to the macosx
>> backend with this addition.
>>
>
> Thanks!
>
>     I am also curious to know what people think of making pylab.show() also
>>    yield the focus to the plot windows in -interactive- mode? All the
>> other
>>    commands update the plot windows automatically, keeping the focus in
>> the
>>    python interpreter. So pylab.show() would only do that: yield the focus
>>    to the plot windows. That is not in the branch (yet).
>>
>>
>> I'd lean toward no: the plot window shouldn't grab focus in interactive
>> mode. I have some scripts that take command-line input in-between plot
>> calls. If the plot window grabbed focus, then I'd have to switch focus
>> back to enter input. This probably isn't a common use case, though.
>>
>
> But you don't use show() in interactive mode, do you? The focus grab would
> not happen until you call show().
>
> I other words, show() would always send the focus to the plot windows. But
> depending on how interactive is set, it would block or not. If you are in
> interactive mode and don't want to send the focus to the plot windows, you
> would have to not call show().
>
> -Julien
>

Good point: my scripts call draw(), instead of show(). Ignore what I said
earlier. :)

-Tony