matplotlib-devel Mailing List for matplotlib (Page 3)

Running backend_driver:
Backend svg took 4.94 minutes to complete
 Failures: ['../pylab_examples/quadmesh_demo.py', '../api/logo2.py', 
'../api/watermark_text.py']
All the other backends passed. It looks like there is a single svg 
problem being triggered by all three of these examples.
Eric

On 08/16/2011 10:10 AM, John Hunter wrote:
> On Mon, Aug 15, 2011 at 9:34 PM, Benjamin Root<ben...@ou...> wrote:
>> The mpl developers are getting very close to the long-awaited v1.1.0 release
>> of matplotlib. Before we do so, we are doing some final checking of the
>> documentation to make sure that all critical pieces of information iss
>> correct and up to date.
>>
>> In checking over the instructions for building and installing matplotlib on
>> MacOSX, I have found two separate sets of instructions. On the install
>> page, there is a reference to a README.txt file in "release/osx". This file
>> is there, but it seems to refer to other files that no longer exists.
>> Meanwhile, there is an un-referenced file in the top directory called
>> README.osx that seems a lot more current.
>>
>> Because I do not have a Mac that I can use for development, I would like to
>> ask the community for help in determining the correct set of instructions
>> and to eliminate cruft. I think it would also be useful to point users to
>> any relevant instructions for installing/building numpy on Macs. I would
>> also like to make sure we are current with information on installing on a
>> stock Lion install.
>>
>> Please feel free to respond on this list, or better, make a branch on github
>> and submit pull requests to help us improve these documents.
>
> I wrote both of those files originally (make.osx and releases/osx/*).
> The original division of labor was the stuff in "releases" was
> designed to build the release binaries, and the stuff in make.osx was
> primarily used to build from svn or src. Overtime, most of the effort
> has gone into make.osx, and it now includes support for binaries. I
> no longer build the OSX binaries (Russell does) and no longer use OS X
> (back to ubuntu) so if Russell is not using the stuff in releases/osx,
> we can flush it.
The releases/win32/ tree is also unmaintained since 0.99.0.rc1. Who 
does the Windows builds these days? Christophe?
It would be nice to have a maintained record of how release builds are 
done, or better yet, up-to-date scripts that fully automate it.
Eric
>
> JDH

On 08/13/2011 08:05 AM, Eike von Seggern wrote:
> Dear developers,
>
> I find the hard-coded "extent" in Axes.matshow limits the usability of
> this method and hence of pyplot.matshow, because passing "origin" does
> switch the order or the rows but does not switch the order of the y-axis
> labels, which I find is counter-intuitive and makes simple
> lower-left-origin plotting of matrices impossible, because row-numbers
> and y-labels are out of sync.
>
> To get the expected behaviour I have to force "extent" to "None" when
> calling matshow and let AxesImage.get_extent work which does the same
> calculations as done in Axes.matshow, but is origin-aware. It is called
> in the constructor of _AxesBaseImage.
>
> Are there strong reasons/use cases for this
> inconsistency between array-ordering and label-ordering? Or could this
> be changed in the future?
It looks like you have found a historical artifact that can be improved 
as you suggest. I will take care of it.
Eric
>
> Kind regards
> eike
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Aug 15, 2011 at 9:34 PM, Benjamin Root <ben...@ou...> wrote:
> The mpl developers are getting very close to the long-awaited v1.1.0 release
> of matplotlib. Before we do so, we are doing some final checking of the
> documentation to make sure that all critical pieces of information iss
> correct and up to date.
>
> In checking over the instructions for building and installing matplotlib on
> MacOSX, I have found two separate sets of instructions. On the install
> page, there is a reference to a README.txt file in "release/osx". This file
> is there, but it seems to refer to other files that no longer exists.
> Meanwhile, there is an un-referenced file in the top directory called
> README.osx that seems a lot more current.
>
> Because I do not have a Mac that I can use for development, I would like to
> ask the community for help in determining the correct set of instructions
> and to eliminate cruft. I think it would also be useful to point users to
> any relevant instructions for installing/building numpy on Macs. I would
> also like to make sure we are current with information on installing on a
> stock Lion install.
>
> Please feel free to respond on this list, or better, make a branch on github
> and submit pull requests to help us improve these documents.
I wrote both of those files originally (make.osx and releases/osx/*).
The original division of labor was the stuff in "releases" was
designed to build the release binaries, and the stuff in make.osx was
primarily used to build from svn or src. Overtime, most of the effort
has gone into make.osx, and it now includes support for binaries. I
no longer build the OSX binaries (Russell does) and no longer use OS X
(back to ubuntu) so if Russell is not using the stuff in releases/osx,
we can flush it.
JDH

In article 
<CANNq6FkoEfKa6F5NOG1-W5PTPaM_xKSGcFEbSGn14n8TsHN3=A...@ma...>,
 Benjamin Root <ben...@ou...> wrote:
> The mpl developers are getting very close to the long-awaited v1.1.0 release
> of matplotlib. Before we do so, we are doing some final checking of the
> documentation to make sure that all critical pieces of information iss
> correct and up to date.
> 
> In checking over the instructions for building and installing matplotlib on
> MacOSX, I have found two separate sets of instructions. On the install
> page, there is a reference to a README.txt file in "release/osx". This file
> is there, but it seems to refer to other files that no longer exists.
> Meanwhile, there is an un-referenced file in the top directory called
> README.osx that seems a lot more current.
> 
> Because I do not have a Mac that I can use for development, I would like to
> ask the community for help in determining the correct set of instructions
> and to eliminate cruft. I think it would also be useful to point users to
> any relevant instructions for installing/building numpy on Macs. I would
> also like to make sure we are current with information on installing on a
> stock Lion install.
> 
> Please feel free to respond on this list, or better, make a branch on github
> and submit pull requests to help us improve these documents.
Building on MacOS X would be just like unix if setupext.py did not have 
the MacOS X-specific stuff commented out. The libraries are here on 
MacOS X:
/usr/X11/lib/ for libpng and libfreetype
/usr/lib/ for libz
That would greatly simplify the readme files.
That said, some Mac users like to use MacPorts, fink or similar software 
to install unix tools. I don't know what happens if those are used. One 
solution is to not search those directories by default and suggest that 
users edit setupext.py if they wish to use those versions.
There are, or were, also files that create the Mac binary installers 
using "make". I suspect one of the readme files you are asking about 
refer to those files. I have no idea if those files still work. I make 
those binaries now, and I do it by hand. Last I looked, those files were 
in the repository, but for some reason were excluded from the source 
distribution.
-- Russell

The mpl developers are getting very close to the long-awaited v1.1.0 release
of matplotlib. Before we do so, we are doing some final checking of the
documentation to make sure that all critical pieces of information iss
correct and up to date.
In checking over the instructions for building and installing matplotlib on
MacOSX, I have found two separate sets of instructions. On the install
page, there is a reference to a README.txt file in "release/osx". This file
is there, but it seems to refer to other files that no longer exists.
Meanwhile, there is an un-referenced file in the top directory called
README.osx that seems a lot more current.
Because I do not have a Mac that I can use for development, I would like to
ask the community for help in determining the correct set of instructions
and to eliminate cruft. I think it would also be useful to point users to
any relevant instructions for installing/building numpy on Macs. I would
also like to make sure we are current with information on installing on a
stock Lion install.
Please feel free to respond on this list, or better, make a branch on github
and submit pull requests to help us improve these documents.
Thanks!
Ben Root

On 08/15/2011 12:07 PM, Eric Firing wrote:
> JJ,
>
> Thanks for your fast fix of the last problem I reported.
>
> Now that the doc build is trying to run scripts with the __main__
> conditional, one of the examples it is tripping over is
> make_room_for_ylabel_using_axesgrid.py.
>
> When I try to run it on the command line or in ipython, it displays
> nothing at all. I suspect that is related to the failure in the doc
> build, but I haven't looked into it at all. (In the doc build it
> generates a huge traceback ending in
> RuntimeError: maximum recursion depth exceeded in __instancecheck__
> ).
Correction: running it from the command line generates the same problem 
as is seen in the doc build and described above.
Eric

JJ,
Thanks for your fast fix of the last problem I reported.
Now that the doc build is trying to run scripts with the __main__ 
conditional, one of the examples it is tripping over is 
make_room_for_ylabel_using_axesgrid.py.
When I try to run it on the command line or in ipython, it displays 
nothing at all. I suspect that is related to the failure in the doc 
build, but I haven't looked into it at all. (In the doc build it 
generates a huge traceback ending in
RuntimeError: maximum recursion depth exceeded in __instancecheck__
).
Eric

Hi Stan,
this size problem sounds somewhat familiar to me. I had a serious
headache to get the interaction of wx.ScrolledWindow, wx.BoxSizer and
matplotlib.backends.backend_wxagg.FigureCanvasWxAgg right when zooming a
canvas in and out and resizing the window.
I am not sure if it will help you, but I've attached how exactly I set
up the three elements to behave as I wish. Unrelated code is stripped
from the example.
Hope that helps!
Dieter
Am Montag, den 15.08.2011, 13:30 -0400 schrieb Stan West:
> From: Stan West [mailto:sta...@nr...] 
> Sent: Monday, August 15, 2011 13:21
> 
> From: David Just [mailto:Jus...@ma...] 
> Sent: Friday, August 12, 2011 11:05
> 
> 
> Now that I’m pre-building all my enlarged interpolated
> images to scroll through, I’m having trouble forcing
> the figure/FigureCanvas to be the size I want.
> 
> I’m trying: 
> fig.set_size_inches(768 / 72.0, 768 / 72.0), but it
> ends up the same size as the default plot.
> 
> If the issue is that the GUI window is not changing size, try
> adding "forward=True" to the set_size_inches call. 
> 
> Developers:
> 
> As I was checking this with v. 1.0.1, I noticed that the Qt4Agg and
> TkAgg backends are inconsistent in how they set the size of a figure.
> Here is the Qt4Agg behavior:
> 
> >>> fig = plt.figure(figsize=[6, 4])
> >>> print fig.get_size_inches()
> [ 6. 3.97916667]
> >>> fig.set_size_inches([6, 4], forward=True)
> >>> print fig.get_size_inches()
> [ 6. 3.4375]
> 
> The initial figure size isn't quite right, and the size after
> set_size_inches is worse. (Is the resize ignoring the toolbar height?)
> Here is the TkAgg behavior:
> 
> >>> fig = plt.figure(figsize=[6, 4])
> >>> print fig.get_size_inches()
> [ 6.125 4.125]
> >>> fig.set_size_inches([6, 4], forward=True)
> >>> print fig.get_size_inches()
> [ 6. 3.64583333]
> 
> Again, the initial size is off (due to the window border?), and the
> resized size is incorrect (toolbar again?).
> 
> The WXAgg backend correctly sets the figure canvas to the desired
> size:
> 
> >>> fig = plt.figure(figsize=[6, 4])
> >>> print fig.get_size_inches()
> [ 6. 4.]
> >>> fig.set_size_inches([6, 4], forward=True)
> >>> print fig.get_size_inches()
> [ 6. 4.]
> 
> I didn't check any other backends.
> 
> I didn't see any indication in the master branch that this behavior
> has changed since 1.0.1. I didn't find a report for this issue on the
> tracker; shall I create one?
> 
> 
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model 
> configuration take the hassle out of deploying and managing Subversion and 
> the tools developers use with it. Learn more about uberSVN and get a free 
> download at: http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

From: Stan West [mailto:sta...@nr...] 
Sent: Monday, August 15, 2011 13:21
From: David Just [mailto:Jus...@ma...] 
Sent: Friday, August 12, 2011 11:05
 
Now that I'm pre-building all my enlarged interpolated images to scroll
through, I'm having trouble forcing the figure/FigureCanvas to be the size I
want.
I'm trying: 
fig.set_size_inches(768 / 72.0, 768 / 72.0), but it ends up the same size as
the default plot.
If the issue is that the GUI window is not changing size, try adding
"forward=True" to the set_size_inches call. 
Developers:
As I was checking this with v. 1.0.1, I noticed that the Qt4Agg and TkAgg
backends are inconsistent in how they set the size of a figure. Here is the
Qt4Agg behavior:
>>> fig = plt.figure(figsize=[6, 4])
>>> print fig.get_size_inches()
[ 6. 3.97916667]
>>> fig.set_size_inches([6, 4], forward=True)
>>> print fig.get_size_inches()
[ 6. 3.4375]
The initial figure size isn't quite right, and the size after set_size_inches
is worse. (Is the resize ignoring the toolbar height?) Here is the TkAgg
behavior:
>>> fig = plt.figure(figsize=[6, 4])
>>> print fig.get_size_inches()
[ 6.125 4.125]
>>> fig.set_size_inches([6, 4], forward=True)
>>> print fig.get_size_inches()
[ 6. 3.64583333]
Again, the initial size is off (due to the window border?), and the resized
size is incorrect (toolbar again?).
The WXAgg backend correctly sets the figure canvas to the desired size:
>>> fig = plt.figure(figsize=[6, 4])
>>> print fig.get_size_inches()
[ 6. 4.]
>>> fig.set_size_inches([6, 4], forward=True)
>>> print fig.get_size_inches()
[ 6. 4.]
I didn't check any other backends.
I didn't see any indication in the master branch that this behavior has
changed since 1.0.1. I didn't find a report for this issue on the tracker;
shall I create one?

I ran into some failures while trying to build the docs from master. 
Here is one, illustrated via running an example directly.
efiring@manini:~/programs/py/mpl/matplotlib/doc$ python 
/home/efiring/programs/py/mpl/matplotlib/doc/mpl_toolkits/axes_grid/figures/demo_parasite_axes.py
Traceback (most recent call last):
 File 
"/home/efiring/programs/py/mpl/matplotlib/doc/mpl_toolkits/axes_grid/figures/demo_parasite_axes.py", 
line 47, in <module>
 host.legend()
 File "/usr/local/lib/python2.7/dist-packages/matplotlib/axes.py", 
line 4427, in legend
 handles, labels = self.get_legend_handles_labels()
 File "/usr/local/lib/python2.7/dist-packages/matplotlib/axes.py", 
line 4262, in get_legend_handles_labels
 for handle in self._get_legend_handles(legend_handler_map):
 File 
"/usr/local/lib/python2.7/dist-packages/mpl_toolkits/axes_grid1/parasite_axes.py", 
line 263, in _get_legend_handles
 all_handles.extend(ax._get_legend_handles)
TypeError: 'instancemethod' object is not iterable
Eric

Dear developers,
I find the hard-coded "extent" in Axes.matshow limits the usability of
this method and hence of pyplot.matshow, because passing "origin" does
switch the order or the rows but does not switch the order of the y-axis
labels, which I find is counter-intuitive and makes simple
lower-left-origin plotting of matrices impossible, because row-numbers
and y-labels are out of sync.
To get the expected behaviour I have to force "extent" to "None" when
calling matshow and let AxesImage.get_extent work which does the same
calculations as done in Axes.matshow, but is origin-aware. It is called
in the constructor of _AxesBaseImage.
Are there strong reasons/use cases for this
inconsistency between array-ordering and label-ordering? Or could this
be changed in the future?
Kind regards
 eike

On 8/11/11 4:11 AM, Pavel Raiskup wrote:
> Hi,
>
>> Coverity is an interesting product and I heard of it before on
>> TheDailyWTF.com (in positive light, of course!). However, it appears 
>> that
>> you were scanning an outdated version of our software. The current 
>> release
>> version is v1.0.1, and we are poised to do another release soon. The
>> current version of our software can be found at
>> https://github.com/matplotlib/ (there are separate matplotlib and 
>> basemap
>> repos). I would certainly be interested in the results on that.
>
> Hi, I've checked last results of coverity against svn version and 
> these filtered
> defects are present there also (not only in version 0.9.4) but I have 
> made new
> scan for you on trunk code. The coverity error log is attached.
>
> python-basemap-1.0.2.err (defects in hand-written source)
> python-basemap-1.0.2.gc (defects in generated code)
>
>> However, if RedHat is interested in packaging matplotlib in a release of
>> RHEL (I know a lot of people at NOAA, NWS and NSSL who would appreciate
>> that) and there is a particular version of matplotlib that you have 
>> selected
>> for packaging, we can certainly work with you on that.
>
> We are not currently planning packaging matplotlib in RHEL. Coverity's 
> scans are
> done on wide range of package canditates for next RHEL but it does not 
> necessary
> mean that matplotlib will be included. There is long way to this yet.. 
> and
> I can not affect this unfortunately.
>
> Howeever, if you would like to help with packaging in Fedora, you 
> could try to
> contact python-basemap's maintainer in Fedora.
>
> Thank you,
> Pavel
These warnings all are either in cython generated code, or proj4 library 
code. Since cython code is automatically generated, I can't fix those. 
I don't want to change the proj4 library routines either, since they are 
externally maintained.
-Jeff

Hi,
> Coverity is an interesting product and I heard of it before on
> TheDailyWTF.com (in positive light, of course!). However, it appears 
> that
> you were scanning an outdated version of our software. The current 
> release
> version is v1.0.1, and we are poised to do another release soon. The
> current version of our software can be found at
> https://github.com/matplotlib/ (there are separate matplotlib and basemap
> repos). I would certainly be interested in the results on that.
Hi, I've checked last results of coverity against svn version and these 
filtered
defects are present there also (not only in version 0.9.4) but I have made 
new
scan for you on trunk code. The coverity error log is attached.
 python-basemap-1.0.2.err (defects in hand-written source)
 python-basemap-1.0.2.gc (defects in generated code)
> However, if RedHat is interested in packaging matplotlib in a release of
> RHEL (I know a lot of people at NOAA, NWS and NSSL who would appreciate
> that) and there is a particular version of matplotlib that you have 
> selected
> for packaging, we can certainly work with you on that.
We are not currently planning packaging matplotlib in RHEL. Coverity's 
scans are
done on wide range of package canditates for next RHEL but it does not 
necessary
mean that matplotlib will be included. There is long way to this yet.. and
I can not affect this unfortunately.
Howeever, if you would like to help with packaging in Fedora, you could 
try to
contact python-basemap's maintainer in Fedora.
Thank you,
Pavel

There is some documentation about the change from 0.98 to 0.99 here:
http://matplotlib.sourceforge.net/api/api_changes.html
Mike
On 08/10/2011 12:11 PM, Benjamin Root wrote:
> On Wed, Aug 10, 2011 at 10:32 AM, Viktor Nagy <vik...@to... 
> <mailto:vik...@to...>> wrote:
>
> Hi,
>
> I would like to port the faces project management app [1] to
> current matplotlib. Actually, I'm not the maintainer of faces, and
> I'm new to matplotlib. But I'll read as much as necessary.
>
> First, I've tried to install faces v0.11.7, but it fails with a
> matplotlib import:
>
> import matplotlib.transforms as _mtrans
> import matplotlib.patches as _patches
> import matplotlib.numerix as _numerix
> import matplotlib.font_manager as _font
>
> and later
>
> _minus = _mtrans.Value(-1)
> _value_type = type(_minus)
>
> finally
>
> actually, it fails at the first line.
>
> I've searched the docs, but could not find anything before v0.98,
> while the faces website says that v0.85 is required.
>
> Could someone point me to some documentation, or provide me
> guidelines on porting faces to recent matplotlib versions?
>
> thx
>
> [1]: faces.homeip.net <http://faces.homeip.net>
>
>
> What is likely to be causing the bigger issue is not incompatibility 
> with matplotlib (although I hope faces has some sort of test suite to 
> make sure the behavior is still as intended). The bigger problem is 
> porting faces to use numpy instead of numerix. I would try 
> researching that problem first.
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at: http://p.sf.net/sfu/wandisco-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Wed, Aug 10, 2011 at 10:32 AM, Viktor Nagy <vik...@to...>wrote:
> Hi,
>
> I would like to port the faces project management app [1] to current
> matplotlib. Actually, I'm not the maintainer of faces, and I'm new to
> matplotlib. But I'll read as much as necessary.
>
> First, I've tried to install faces v0.11.7, but it fails with a matplotlib
> import:
>
> import matplotlib.transforms as _mtrans
> import matplotlib.patches as _patches
> import matplotlib.numerix as _numerix
> import matplotlib.font_manager as _font
>
> and later
>
> _minus = _mtrans.Value(-1)
> _value_type = type(_minus)
>
> finally
>
> actually, it fails at the first line.
>
> I've searched the docs, but could not find anything before v0.98, while the
> faces website says that v0.85 is required.
>
> Could someone point me to some documentation, or provide me guidelines on
> porting faces to recent matplotlib versions?
>
> thx
>
> [1]: faces.homeip.net
>
>
What is likely to be causing the bigger issue is not incompatibility with
matplotlib (although I hope faces has some sort of test suite to make sure
the behavior is still as intended). The bigger problem is porting faces to
use numpy instead of numerix. I would try researching that problem first.
Ben Root

Hi,
I would like to port the faces project management app [1] to current
matplotlib. Actually, I'm not the maintainer of faces, and I'm new to
matplotlib. But I'll read as much as necessary.
First, I've tried to install faces v0.11.7, but it fails with a matplotlib
import:
import matplotlib.transforms as _mtrans
import matplotlib.patches as _patches
import matplotlib.numerix as _numerix
import matplotlib.font_manager as _font
and later
_minus = _mtrans.Value(-1)
_value_type = type(_minus)
finally
actually, it fails at the first line.
I've searched the docs, but could not find anything before v0.98, while the
faces website says that v0.85 is required.
Could someone point me to some documentation, or provide me guidelines on
porting faces to recent matplotlib versions?
thx
[1]: faces.homeip.net

Hi all,
While playing around with scatter plots, I noticed something strange
about the colors displayed. For example,
f = plt.figure()
ax = f.gca(projection='3d')
ax.scatter([1,2,3], [1,2,3], [1,2,3], 'o', c=[(0,0,1,1), (0,0,0,1), (1,0,0,1)])
plt.show()
should show a blue, a black and a red dot. Instead, my first dot is
grey. It's almost as if the axes "panels" are displayed over it. Is
this a bug, or am I doing something I shouldn't?
Regards
Stéfan

On Wed, Aug 3, 2011 at 2:53 PM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Aug 3, 2011 at 2:42 PM, Eric Firing <ef...@ha...> wrote:
>>
>> Can we please just release something now, so Debian doesn't have to come
>> up with their own modification of 1.0.1?
>>
>> Eric
>>
>
> As far as I am concerned, the only thing stopping us from releasing is:
>
> 1) There are figures that are failing to be generated by sphinx. I have
> noticed that all failed figures come from example code that uses "if
> __name__ == '__main__'" in the source. I have not investigated this
> further.
>
> 2) Need to update the docs to point to new bug-tracker, refer to the new
> version number in the main sidebar, and add a "What's New" section.
>
> To me, everything else is incidental and are not show-stoppers.
And Sandro mentioned this via about the ipython directive and console
highlighting: "You need to update ipython_directive.py and
ipython_console_highlighting.py.
Newer versions are available in the ipython source but they are not well
tested yet, please report problems upstream."
JDH

On Wed, Aug 3, 2011 at 2:42 PM, Eric Firing <ef...@ha...> wrote:
> Can we please just release something now, so Debian doesn't have to come
> up with their own modification of 1.0.1?
>
> Eric
>
>
As far as I am concerned, the only thing stopping us from releasing is:
1) There are figures that are failing to be generated by sphinx. I have
noticed that all failed figures come from example code that uses "if
__name__ == '__main__'" in the source. I have not investigated this
further.
2) Need to update the docs to point to new bug-tracker, refer to the new
version number in the main sidebar, and add a "What's New" section.
To me, everything else is incidental and are not show-stoppers.
Ben Root

Can we please just release something now, so Debian doesn't have to come 
up with their own modification of 1.0.1?
Eric
-------- Original Message --------
Subject: Re: [matplotlib] Provide ipython 0.11 compatibility (#411)
Date: 2011年8月03日 11:28:03 -0700
From: sandrotosi 
<rep...@re...>
To: ef...@ha...
Hi Eric,
On Wed, Aug 3, 2011 at 19:59, efiring
<re...@re...>
wrote:
> As far as I know, mpl master is fully consistent with IPython 0.11. Do
> you have evidence or examples to the contrary?
Sorry I was too dense :)
Currently in Debian we provide mpl 1.0.1 and we'd like to also ship
ipython 0.11 . I've received a bug report where it states that mpl
1.0.1 needs to be adapted in order to work correctly with ipy 0.11
(and I hope the reported did his homework before submitting :) .
 From your reply I guess there was some work that it's maybe only on
master and was not released with 1.0.1 ? If so, can you please point
me to the relevant commits, so I can cherrypick them and update the
debian package?
I tried a very basic example, "plot([1, 2], [2, 4])", and it works
fine, but there might be some other snippets failing.
Thanks for your help,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
-- 
Reply to this email directly or view it on GitHub:
https://github.com/matplotlib/matplotlib/issues/411#issuecomment-1720408

Hi,
I will be on vacation with limited email from July 14 to August 7, 2011.
Bonjour,
Je serai en conge du 14 juillet jusqu'au 7 aout, 2011.

2011年7月28日 Pavel Raiskup <pra...@re...>
> Hi,
>
> I would like to report some issues in python basemap package and easy-fixes
> for
> some of them. We would really appreciate if there was somebody who could
> look
> on this and consider important bugs to be fixed.
>
> These bugs was found by Coverity scan and we have ran it on Fedora 15
> packages (srpm). There was some findings in python basemap package also.
> Coverity
> is proprietary software but we can give its result to community (if
> interrested),
> possibly we can re-run some tests on srpms on demand.
>
> Patch for next three obvious bugs (plaintext cov. output) is attached:
>
> Error: OVERRUN_STATIC:
> basemap-0.99.4/src/pj_**gridlist.c:252: overrun-local: Overrunning static
> array "name", with 128 elements, at position 128 with index variable
> "end_char".
>
> Error: UNINIT:
> basemap-0.99.4/src/mk_cheby.c:**42: var_decl: Declaring variable "T"
> without initializer.
> basemap-0.99.4/src/mk_cheby.c:**150: uninit_use: Using uninitialized value
> "T".
> basemap-0.99.4/src/mk_cheby.c:**151: uninit_use: Using uninitialized value
> "T->mu".
> basemap-0.99.4/src/mk_cheby.c:**152: uninit_use: Using uninitialized value
> "T->cu".
> basemap-0.99.4/src/mk_cheby.c:**154: uninit_use: Using uninitialized value
> "T->mv".
> basemap-0.99.4/src/mk_cheby.c:**155: uninit_use: Using uninitialized value
> "T->cv".
> basemap-0.99.4/src/mk_cheby.c:**163: uninit_use: Using uninitialized value
> "T".
>
> Error: NO_EFFECT:
> basemap-0.99.4/src/PJ_sconics.**c:52: self_assign: Assignment operation
> "*del = *del" has no effect.
>
> __________________________
>
> But there is more defects (or coding style issues) and some of them are not
> so obvious. There could be potential problems -- need to be consulted,
> e.g.:
>
> Error: EVALUATION_ORDER:
> basemap-0.99.4/src/PJ_stere.c:**232: write_write_order: In "P->phits =
> (pj_param(P->params, "tlat_ts").i ? P->phits = pj_param(P->params,
> "rlat_ts").f : 1.5708)", "P->phits" is written in "P->phits" (the assignment
> left-hand side) and written in "pj_param(P->params, "tlat_ts").i ? P->phits
> = pj_param(P->params, "rlat_ts").f : 1.5708" but the order in which the side
> effects take place is undefined because there is no intervening sequence
> point.
>
> Error: FORWARD_NULL:
> basemap-0.99.4/src/emess.c:29: var_compare_op: Comparing "fmt" to null
> implies that "fmt" might be null.
> basemap-0.99.4/src/emess.c:51: var_deref_model: Passing null variable "fmt"
> to function "vfprintf", which dereferences it.
>
> Error: FORWARD_NULL:
> basemap-0.99.4/src/pj_**gridinfo.c:505: var_compare_op: Comparing "gp" to
> null implies that "gp" might be null.
> basemap-0.99.4/src/pj_**gridinfo.c:512: alias_transfer: Assigning null:
> "lnk" = "gp".
> basemap-0.99.4/src/pj_**gridinfo.c:512: var_deref_op: Dereferencing null
> variable "lnk".
>
> Error: FORWARD_NULL:
> basemap-0.99.4/src/pj_ell_set.**c:30: var_compare_op: Comparing
> "start->next" to null implies that "start->next" might be null.
> basemap-0.99.4/src/pj_ell_set.**c:92: var_deref_op: Dereferencing null
> variable "start->next".
>
> Coverity test was done on:
> http://sourceforge.net/**projects/matplotlib/files/**
> matplotlib-toolkits/basemap-0.**99.4/basemap-0.99.4.tar.gz<http://sourceforge.net/projects/matplotlib/files/matplotlib-toolkits/basemap-0.99.4/basemap-0.99.4.tar.gz>
>
> ..so svn version is little different (line numbers) but it can be handy for
> finding hidden bugs. I can send you full plain-text log if you want.
>
> Pavel
>
>
Pavel,
Coverity is an interesting product and I heard of it before on
TheDailyWTF.com (in positive light, of course!). However, it appears that
you were scanning an outdated version of our software. The current release
version is v1.0.1, and we are poised to do another release soon. The
current version of our software can be found at
https://github.com/matplotlib/ (there are separate matplotlib and basemap
repos). I would certainly be interested in the results on that.
However, if RedHat is interested in packaging matplotlib in a release of
RHEL (I know a lot of people at NOAA, NWS and NSSL who would appreciate
that) and there is a particular version of matplotlib that you have selected
for packaging, we can certainly work with you on that.
Ben Root

I probably should have sent this to the devel list instead of the user list.
Is anyone else running into a similar problem with Qt, or is something in my
install screwy?
Thanks,
-Tony
---------- Forwarded message ----------
From: Tony Yu <ts...@gm...>
Date: Mon, Jul 18, 2011 at 5:58 PM
Subject: IOError: [Errno 4] Interrupted system call (Qt4 backend)
To: matplotlib-users <mat...@li...>
When using the Qt4 backend, I'm getting an IOError similar to the one
detailed in:
http://old.nabble.com/matplotlib-with-Qt4-backend-td26311369.html
But it's definitely a separate issue (see Traceback below). This issue also
seems specific to Qt (I couldn't reproduce it on 'macosx', 'tkagg', or 'agg'
backends).
I found a number of other people who ran into similar problems with Qt.
Their solutions tend to be: catch the error and just try running the process
again.
I'm on Qt 4.7.3, OS X 10.6.8, Matplotlib trunk. Any help would be much
appreciated.
-Tony
Script reproducing issue
========================
import matplotlib
matplotlib.use('qt4agg')
import matplotlib.pyplot as plt
for n in xrange(300):
 plt.plot([0, 1])
 plt.savefig('test.jpg')
# Since it's a signaling issue, it gets triggered randomly, so the attached
# script may or not reproduce the issue.
Traceback
=========
traceback (most recent call last):
 File "qterror.py", line 8, in <module>
 plt.savefig('test.jpg')
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/pyplot.py", line 428, in
savefig
 return fig.savefig(*args, **kwargs)
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/figure.py", line 1162,
in savefig
 self.canvas.print_figure(*args, **kwargs)
 File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4agg.py",
line
 153, in print_figure
 FigureCanvasAgg.print_figure(self, *args, **kwargs)
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
1979, in
print_figure
 **kwargs)
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
1799, in
print_jpg
 buf, size = agg.print_to_buffer()
 File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
45
7, in print_to_buffer
 FigureCanvasAgg.draw(self)
 File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
40
0, in draw
 self.renderer = self.get_renderer()
 File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
41
1, in get_renderer
 self.renderer = RendererAgg(w, h, self.figure.dpi)
 File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
51
, in __init__
 RendererBase.__init__(self)
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
114, in _
_init__
 self._text2path = textpath.TextToPath()
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/textpath.py", line 37,
in __init_
_
 self._adobe_standard_encoding = self._get_adobe_standard_encoding()
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/textpath.py", line 41,
in _get_ad
obe_standard_encoding
 enc_name = dviread.find_tex_file('8a.enc')
 File "/Users/Tony/python/devel/mpl/lib/matplotlib/dviread.py", line 837,
in find_te
x_file
 result = pipe.communicate()[0].rstrip()
 File
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/subpro
cess.py", line 663, in communicate
 stdout = self.stdout.read()
IOError: [Errno 4] Interrupted system call