matplotlib-devel Mailing List for matplotlib (Page 19)

My sincere apologies for the multiple copies of the e-mail sent this 
morning. I was getting "SMTP server down" messages, but clearly the 
messages were sent anyway.
I'm not a spammer, really! ;)
Mike

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 upgrade. There are binary packages available for
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release, but I thought it was worth trying.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 upgrade. There are binary packages available for
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release, but I thought it was worth trying.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose 
class subclasses a Wx class. There is a fix for this that made it into 
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
<http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1>
I have verified this on my source-built wxPython-2.8.4.0. If I remove 
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to 
wxPython-2.8.4 should upgrade. There are binary packages available for 
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know 
if this qualifies for the kind of fix they would normally make as a 
maintenance release. Promisingly, my bug was confirmed within about 
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381 
<https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381>
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 upgrade. There are binary packages available for
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release, but I thought it was worth trying.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 should upgrade. There are binary packages available for
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release. Promisingly, my bug was confirmed within about
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose
class subclasses a Wx class. There is a fix for this that made it into
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
I have verified this on my source-built wxPython-2.8.4.0. If I remove
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to
wxPython-2.8.4 should upgrade. There are binary packages available for
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know
if this qualifies for the kind of fix they would normally make as a
maintenance release. Promisingly, my bug was confirmed within about
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose 
class subclasses a Wx class. There is a fix for this that made it into 
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
<http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1>
I have verified this on my source-built wxPython-2.8.4.0. If I remove 
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to 
wxPython-2.8.4 should upgrade. There are binary packages available for 
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know 
if this qualifies for the kind of fix they would normally make as a 
maintenance release. Promisingly, my bug was confirmed within about 
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381 
<https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381>
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

On 7/6/07, Michael Droettboom <md...@st...> wrote:
> I don't know the root cause, but FYI I'm definitely getting rasterized
> text with the Cairo backend for mathtext_demo.py. (I'm using
> cairo-1.4.10, which I believe is the latest stable release).
And you are pretty sure it is all the text, not just the mathtext? We
do use special fonts for mathtext (the Backoma cm ttf fonts) and
perhaps something funny is going on with them? But that should not
affect non-mathtext in the same figure.
What about simple_demo.py -- do you get rasters there too?
JDH

I had no trouble reproducing this on my Ubuntu Feisty box.
It turns out that wxPython leaks a dictionary for every object whose 
class subclasses a Wx class. There is a fix for this that made it into 
wxPython-2.8.3.0:
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1 
<http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/wxPython/src/helpers.cpp.diff?r1=1.145&r2=1.145.4.1>
I have verified this on my source-built wxPython-2.8.4.0. If I remove 
this line, I can reproduce the reference leak.
** I would recommend that anyone using a wxPython-2.8.x prior to 
wxPython-2.8.4 should upgrade. There are binary packages available for 
a number of distributions on wxpython.org. **
As an aside, I filed a bug for this on Ubuntu launchpad. I don't know 
if this qualifies for the kind of fix they would normally make as a 
maintenance release. Promisingly, my bug was confirmed within about 
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381 
<https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381>
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

Carl Worth wrote:
>> don't think it is supported in cairo. So I am not sure where these
>> rasters are coming from, unless cairo is converting all text to
>> rasters.
>> 
>
> Definitely not converting all text to raster, (unless someone's using
> an ancient version of cairo).
> 
I don't know the root cause, but FYI I'm definitely getting rasterized 
text with the Cairo backend for mathtext_demo.py. (I'm using 
cairo-1.4.10, which I believe is the latest stable release).
Cheers,
Mike

 Hi all,
The svn version raises a name error.
Traceback (most recent call last):
 File "lshape.py", line 49, in ?
 figure(1)
 File "/usr/lib64/python2.4/site-packages/matplotlib/pylab.py", line
865, in figure
 figManager = new_figure_manager(num, figsize=figsize, dpi=dpi,
facecolor=facecolor, edgecolor=edgecolor, frameon=frameon, Fi 
gureClass=FigureClass, **kwargs)
 File
"/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_wxagg.py",
line 135, in new_figure_manager
 backend_wx._create_wx_app()
 File
"/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_wx.py",
line 1221, in _create_wx_app
 _create_wx_app.theWxApp = app
NameError: global name 'app' is not defined
Nils

Carl Worth wrote:
> On 2007年7月05日 13:22:11 -1000, Eric Firing wrote:
[...]
> 
> My suggestion would be to make it default to .png if no additional
> information is provided, and then to also add some sort of pseudo
> backends so that the other cairo-supported file types could easily be
> obtained with this same savefig call. For example something like:
> 
> 	python myscript.py -dCairoPDF
> 
> What do you think? Would that be simple to implement?
It's done, except that it is '-dCairo.pdf'.
Also, examples/backend_driver.py now supports case-insensitive 
specifation of backends, and the same form of cairo specification. See 
docstring at the top.
I found that the cairo backend writes ps files but not eps--it enlists 
backend_ps for eps files. Does pycairo not have a way to specify eps 
rather than ps output?
Eric
> 
> -Carl
> 
> PS. I'd be more inclined to name the backends things like cairo-pdf
> than CairoPDF but it seems that the latter better fits the existing
> convention for matplotlib backend naming.

Norbert,
I just did the rename, and it worked:
efiring@manini:~/programs/py/mpl/matplotlib_units$ svn move 
lib/matplotlib/rcdefaults.py lib/matplotlib/rcsetup.py
A lib/matplotlib/rcsetup.py
D lib/matplotlib/rcdefaults.py
efiring@manini:~/programs/py/mpl/matplotlib_units$ svn status
? CXX.new
? svn-commit.2.tmp
? test.png
? svn-commit.tmp
? unit/legend_unit.png
? lib/svn-commit.tmp
D lib/matplotlib/rcdefaults.py
A + lib/matplotlib/rcsetup.py
? examples/units/basic_units.pyc
efiring@manini:~/programs/py/mpl/matplotlib_units$ svn commit
Zed V1.0.3 by Sandro Serafini (c) 1997/98
Loading /home/efiring/.zedxrc...
Reading /home/efiring/myzed.cfg...
Resuming /home/efiring/.zedxrc...
Deleting lib/matplotlib/rcdefaults.py
Adding lib/matplotlib/rcsetup.py
Committed revision 3465.
I also changed __init__.py to import rcsetup in a revision that followed 
by about 2 minutes--so I hope no one did an svn update during that interval.
I have no idea what cause your svn commit failure.
Eric
Norbert Nemec wrote:
> I just tried to commit a rename of 'rcdefaults.py' to 'rcsetup.py', but
> I got an error:
> 
> -------------
> ...$ svn commit -m"renamed rcdefaults.py to rccsetup.py to avoid conflict"
> Sending matplotlib/__init__.py
> Deleting matplotlib/rcdefaults.py
> Adding matplotlib/rcsetup.py
> svn: Commit failed (details follow):
> svn: COPY of rcsetup.py: 403 Forbidden (https://svn.sourceforge.net)
> -------------
> 
> If anybody knows what the reason for this might be, please let me know...
> 
> Greetings,
> Norbert
> 

Carl Worth wrote:
> On 2007年7月05日 13:22:11 -1000, Eric Firing wrote:
>> I have made a few changes in svn to facilitate testing cairo with
>> backend_driver (and to fix a bug that turned up), and I will do a bit
>> more on this later today or tomorrow.
> 
> Cool. I've started downloading all the matplotlib source history with
> git-svn, so once that's done I'll take a look. Hopefully it's obvious
> how to run through the cairo backend with the test suite---otherwise
> I'll ask.
> 
>> The result of a quick pass
>> through the backend_driver test with png output is quite encouraging,
>> though. There are some bugs in string placement, image handling, and
>> clipping, but most things work, including mathtext. Default fonts seem
>> to be different.
> 
> If there's anything I can do to help I'll do what I can---let me know.
Thanks. One place to start would be with the string placement. If you 
compare png output from Cairo vs Agg, I think you will find that strings 
are being positioned differently, sometimes very subtly, sometimes 
(especially for plot title) by quite a bit. If you can figure out where 
the differences are coming from, we can decide whether changes are 
needed in Cairo, in one or more of the other backends, or both. (I 
think SVG also positions strings quite differently; I think ps 
positioning is much closer to Agg.)
> 
> Oh, and I meant to say that it's a bit annoying that
> savefig("somefile") doesn't work with the cairo backend. My
> understanding is that this is supposed to automatically select the
> correct file extension based on the backend type, (with the implicit
> assumption that any given backend only supports one backend type).
> 
> That seems like a useful way of using savefig, and I don't think it's
> correct to break it just because cairo supports multiple file types.
> 
> My suggestion would be to make it default to .png if no additional
> information is provided, and then to also add some sort of pseudo
Yes, I was looking at making that the default.
> backends so that the other cairo-supported file types could easily be
> obtained with this same savefig call. For example something like:
> 
> 	python myscript.py -dCairoPDF
> 
> What do you think? Would that be simple to implement?
I think it would be easy. It might be done most easily and consistently 
via the rc mechanism. Figure.savefig already has a kwarg for it, so it 
would be a matter of having that kwarg default to the rc setting. For 
the backend specification I would suggest "-dCairo.pdf" etc, which is 
mnemonic and easy to parse.
Eric
> 
> -Carl
> 
> PS. I'd be more inclined to name the backends things like cairo-pdf
> than CairoPDF but it seems that the latter better fits the existing
> convention for matplotlib backend naming.

On 2007年7月05日 13:22:11 -1000, Eric Firing wrote:
> I have made a few changes in svn to facilitate testing cairo with
> backend_driver (and to fix a bug that turned up), and I will do a bit
> more on this later today or tomorrow.
Cool. I've started downloading all the matplotlib source history with
git-svn, so once that's done I'll take a look. Hopefully it's obvious
how to run through the cairo backend with the test suite---otherwise
I'll ask.
> The result of a quick pass
> through the backend_driver test with png output is quite encouraging,
> though. There are some bugs in string placement, image handling, and
> clipping, but most things work, including mathtext. Default fonts seem
> to be different.
If there's anything I can do to help I'll do what I can---let me know.
Oh, and I meant to say that it's a bit annoying that
savefig("somefile") doesn't work with the cairo backend. My
understanding is that this is supposed to automatically select the
correct file extension based on the backend type, (with the implicit
assumption that any given backend only supports one backend type).
That seems like a useful way of using savefig, and I don't think it's
correct to break it just because cairo supports multiple file types.
My suggestion would be to make it default to .png if no additional
information is provided, and then to also add some sort of pseudo
backends so that the other cairo-supported file types could easily be
obtained with this same savefig call. For example something like:
	python myscript.py -dCairoPDF
What do you think? Would that be simple to implement?
-Carl
PS. I'd be more inclined to name the backends things like cairo-pdf
than CairoPDF but it seems that the latter better fits the existing
convention for matplotlib backend naming.

Carl,
I have made a few changes in svn to facilitate testing cairo with 
backend_driver (and to fix a bug that turned up), and I will do a bit 
more on this later today or tomorrow. The result of a quick pass 
through the backend_driver test with png output is quite encouraging, 
though. There are some bugs in string placement, image handling, and 
clipping, but most things work, including mathtext. Default fonts seem 
to be different.
Eric
Carl Worth wrote:
> On Thu, 5 Jul 2007 13:26:22 -0500, "John Hunter" wrote:
>> On 7/5/07, Carl Worth <cw...@cw...> wrote:
>>> I don't know if there's anything special about the PostScript output
>>> you're currently producing that wouldn't make it acceptable to use
>>> cairo's PostScript output directly. But even if you just want code,
>>> it's inside cairo under the LGPL.
>> I looked at cairo when we first started with the postscript backend,
>> but in the bad old days it was just a raster dump. I understand it
>> has come a long way since.
[...]

On Thu, 5 Jul 2007 14:46:13 -0500, "John Hunter" wrote:
> The postscript backend as it stands is in good shape, and is full
> featured (Darren can tell you how much work he has put into supporting
> and enhancing the latex support). The last major issue with it is the
> font size issue, and with your help a solution is on the horizon. So
> it is definitely a good use of time to fix this last bit. It doesn't
> sound like your "option 2" is a ton of work, but correct me if I'm
> wrong.
For what it's worth, I think I'd be inclined to agree with you
there. If your existing code is working just fine, then switching to
cairo is just more work. But if you do start having to do any serious
maintenance, then you might want to reconsider.
> http://www.scipy.org/License_Compatibility
Thanks, John, for sharing this essay. Please allow me to respond to a
few points:
	In my experience, the benefits of collaborating with the
	private sector are real, whereas the fear that some private
	company will "steal" your product and sell it in a proprietary
	application leaving you with nothing is not.
In my experience, there is real harm that can come when proprietary
modifications to a license made available under a permissive license
are not contributed back. An extremely clear case is that of the X
Window System which went through a period of several independent
software vendors trying to out-compete each other on their own
proprietary modifications to the system, (resulting in the near death
of the system altogether).
I've had some discussions with Jim Gettys about that process and how
the MIT license for X has played out over the years. You argue that a
project most needs the extra users provided by a permissive license
during its formative years until it reaches critical mass and the
network effects kick in. Jim actually argues the point differently and
says that the extra protections of the GPL are most necessary during
the formative period, but not at all needed once the project reaches
critical mass. So I've heard him express that he wishes there were a
way to allow a project to grow under the GPL and then change to
something like the MIT license once it reaches critical
mass.
	There is a lot of GPL code in the world, and it is a constant
	reality in the development of matplotlib that when we want to
	reuse some algorithm, we have to go on a hunt for a non-GPL
	version.
So that's a cost that you need to weigh against the decision to not be
able to accept any GPL code into your project. But I think the fact
that there _is_ a lot of GPL code in the world is a strong argument
against your original thesis that a license more permissible than the
GPL is necessary to bootstrap a free software project to critical
mass. There _is_ a lot of GPL code, which means there _are_ a lot of
users of that code, and a lot of those users are businesses that don't
have a problem using, (and modifying, and contributing back to), GPL
code.
	There are two unpalatable options. 1) Go with GPL and lose the
	mind-share of the private sector 2) Forgo GPL code and retain
	the contribution of the private sector.
You've chosen (2) along with a decision to try to campaign authors of
GPL code to relicense their code as BSD/MIT (ish) whenever you want to
use it. I would guess you'll find that quite difficult in many cases,
(I don't agree that the GPL is most often chosen without intention
just because it is "famous").
I think an easier route to take path (2) is to use the LGPL for your
library, and then only have to convince authors to re-license the
subset of their GPL application code as LGPL that you're actually
interested in incorporating into your library. I would predict that
you will be more successful at that more often than convincing people
to relicense GPL to BSD/MIT (ish).
You only bring the LGPL up at the end of your essay as almost an
afterthought and dismiss it with a very vague, "but many companies are
still loath to use it out of legal concerns". Do you have actual
evidence to point to for that?
It would be simpler if there were direct experiments we could run to
measure some of these things, but there aren't, (and conditions do
continue to change). My experience with the cairo project suggests
that we've been able to achieve a very successful library
implementation, (with plenty of "corporate" contribution), with an
LGPL (and MPL) license.
	This is a very tough decision because their is a lot of very
	high quality software that is GPL and we need to use it;
Network effects are strong---when they're good, don't fight them. :-)
And I've even been annoyed enough with having to get code relicensed
from GPL to LGPL+MPL for use in cairo that I'm thinking the next
library I invent might be simply GPL from the beginning.
Which brings me to my final point. I think it's very interesting (and
worthwhile) to debate license decisions like this. But at the end of
the day, when a project chooses a free software license, and that
project becomes at all "established" it's probably rarely a good idea
to change that license. I just don't think that it's right to engage a
community with one set of ground rules, and then to go and change
those rules out from under the community.
So, even if the current license from matplotlib would allow you to
easily change from it to the LGPL (which I think it does), I wouldn't
make any argument that you should think of changing the project
license.
> don't think it is supported in cairo. So I am not sure where these
> rasters are coming from, unless cairo is converting all text to
> rasters.
Definitely not converting all text to raster, (unless someone's using
an ancient version of cairo).
-Carl

On Thu, 5 Jul 2007 13:26:22 -0500, "John Hunter" wrote:
> On 7/5/07, Carl Worth <cw...@cw...> wrote:
> > I don't know if there's anything special about the PostScript output
> > you're currently producing that wouldn't make it acceptable to use
> > cairo's PostScript output directly. But even if you just want code,
> > it's inside cairo under the LGPL.
>
> I looked at cairo when we first started with the postscript backend,
> but in the bad old days it was just a raster dump. I understand it
> has come a long way since.
Yes, it's definitely a _lot_ better than that now. As of any recent
release of cairo, (1.4.x), you will probably get all-vector output for
the kinds of things I would expect matplotlib to do.
If you do hit something that requires a raster-based fallback in
cairo, (translucence or similar), the current releases of cairo do
still compute the fallback by doing full-page rasterization. But
there's a patch already put together, (by the expert Adrian Johnson),
that makes cairo do rasterization for only the minimal necessary
region, (so expect that in cairo 1.6 in the future).
> mpl's postscript backend supports latex expressions in PS output,
> which requires a fair amount of complex trickery in the postscript
> backend, though we we could probably do it with embedded rasters in
> cairo.
Embedding latex expressions is really cool. If you do try something
like this with cairo and find that you wish cairo would do something
that it can't, then please let me know.
> The postscript backend is also standalone with no dependencies
> other than mpl and numpy, and adding cairo to the mix might be a bit
> difficult for across platforms for some users (though this appears to
> have gotten a lot better too).
Yes, cairo should work extremely well across platforms, (and
particularly the "generic" backends like the image, PDF, PostScript,
and SVG backends). The only outstanding platform-specific issues are in
display-device-specific backends such as in cairo's quartz backend,
(but even it does work extremely well---just not quite perfectly---and
the mozilla people are working hard to complete it).
> LGPL means we cannot reuse the code.
That's your choice of course.
As far as type3 goes, there's really nothing special there. It would
be just as easy (or easier) to just read the PostScript language
reference and implement things directly as compared to reading cairo's
code. That's all I did to write it originally, and it's not hard at
all.
Now, some of the other font subsetting work in cairo is a bit more
sophisticated. Adrian Johnson has done most of that, so he would
probably be the person you would need to ask if you would like the
code to be made available under a more liberal licence than the LGPL,
(or the Mozilla Public License as cairo is currently made available
under either of those).
> While I like the idea of using cairo for both raster and vector
> outputs in principle because it offloads a lot of work onto a large
> and well supported project, it would probably take a fair amount of
> work to get all of mpl's functionality into the cairo backend (I don't
> know this since I have not tested the backend for some time, but does
> it support, for example unicode_demo, mathtext_demo, usetex, and
> image_demo ?).
It doesn't look to me like there's a lot of missing work.
Here are the results from unicode_demo:
	http://www.cworth.org/matplotlib/
To summarize, all of the PNG, PostScript, PDF, and SVG output looks
fine from the cairo backend. Meanwhile, the PDF backend, (as of
0.87.7) seems to generate broken output for the accented characters,
and the SVG backend doesn't position/scale the text correctly.
Cairo's PDF and PostScript output is smaller than matplotlib's native
output, (factor of 2.75), while cairo's SVG output is a fair amount
larger than matplotlib's, (factor of 11), since it's embedding all of
the text glyphs, (which could be either good or bad depending on what
you really want).
I didn't seem to have any usetex demo installed with the Debian 0.87.7
package of python-matplotlib-doc, and with both mathtext_demo and
image_demo I got the following inscrutable error messages:
	/usr/lib/python2.4/site-packages/matplotlib/backends/backend_cairo.py:329:
	UserWarning: cairo with Numeric support is required for
	_draw_mathtext()
	/usr/lib/python2.4/site-packages/matplotlib/backends/backend_cairo.py:162:
	UserWarning: cairo with Numeric support is required for draw_image()
Does anybody know what that could mean? I have no idea what "cairo
with Numeric support" is. Is it perhaps something specific to the
pycairo python bindings of cairo?
-Carl

Ken McIvor wrote:
>> This qualifies as a wx bug, doesn't it?
> I believe so. I'll file it.
I agree - a segfault is ALWAYS a bug.
>> If wx doesn't retain the reference, then instead of a segfault 
>> shouldn't it raise an exception?
> 
> I'd expect wx.GetApp() to work like the rest of wxPython and always 
> return the wx.App instance.
If a wx.App has not been created, it returns None:
 >>> import wx
 >>> wx.GetApp()
 >>> a = wx.GetApp()
 >>> print a
None
Which is probably what it should do if the wxApp() has been deleted.
In any case, you can only create one wxApp per program instance, and it 
can not be destroyed and re-started, so keeping a global instance around 
is probably the way to go.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Jul 5, 2007, at 3:48 PM, Eric Firing wrote:
>
> This qualifies as a wx bug, doesn't it?
I believe so. I'll file it.
> If wx doesn't retain the reference, then instead of a segfault 
> shouldn't it raise an exception?
I'd expect wx.GetApp() to work like the rest of wxPython and always 
return the wx.App instance.
This has been fixed in revision 3463.
Ken

Ken McIvor wrote:
> On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
>>
>> Interesting. I don't get that, but I do get some random segfaults (I
>> got lucky the first time I tested).
> 
> It looks like wxPython doesn't retain a reference to the wxApp PyObj for 
> you:
> 
> kmcivor@400exp209:~/Projects/matplotlib-svn$ pythonw
> Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
> [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import wx
> >>> app = wx.PySimpleApp()
> >>> del app
> >>> wx.GetApp()
> Segmentation fault
This qualifies as a wx bug, doesn't it? If wx doesn't retain the 
reference, then instead of a segfault shouldn't it raise an exception?
Eric

That is at least something to go by. ;)
Thanks,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> And here is the result of the script modified for gtk:
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1
> 55352 55417
> *** <type 'gtk.gdk.Colormap'>
> *** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <type 'gtk.gdk.Window'>
> *** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
> *** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
> *** <type 'gtk.gdk.Pixmap'>
> *** <type 'gtk.Tooltips'>
> *** <type 'gtk.Label'>
> *** <type 'gtk.Window'>
> *** <type 'gtk.VBox'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2
> 55352 55421
> *** <type 'gtk.gdk.Colormap'>
> *** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <type 'gtk.gdk.Window'>
> *** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <type 'gtk.gdk.Window'>
> *** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
> *** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
> *** <type 'gtk.gdk.Pixmap'>
> *** <type 'gtk.Tooltips'>
> *** <type 'gtk.Label'>
> *** <type 'gtk.Window'>
> *** <type 'gtk.VBox'>
>
> uncollectable list: []
>
> Eric
>

Yep. Nothing obvious. I'll have to have a look on Ubuntu and see if 
that makes a difference.
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
>
> Interesting. I don't get that, but I do get some random segfaults (I
> got lucky the first time I tested).
It looks like wxPython doesn't retain a reference to the wxApp PyObj 
for you:
	kmcivor@400exp209:~/Projects/matplotlib-svn$ pythonw
	Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
	[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import wx
	>>> app = wx.PySimpleApp()
	>>> del app
	>>> wx.GetApp()
	Segmentation fault
> I'm awfully surprised that wx.GetApp() would return an iterator, as 
> you
> are getting, so maybe it's corruption of some sort?
My guess is that Eric got lucky and ob_type was pointing to the 
listiterator's C type instance.
> Since I didn't want to just put the wxapp global variable back in, 
> I assigned it to the figure that creates it, therefore stick around 
> as long as the figure does. (Is that the correct thing for its 
> lifetime?)
I don't think this will work if you create two figures, destroy the 
first one, and then create another figure. Once created, the wxApp 
needs to exist for the life of the python process. I'll go ahead an 
put the global variable back in.
> Also, I'm a little puzzled by this code in show() in backend_wx.py:
>
> wxapp = wx.GetApp()
> if wxapp is not None:
> # wxPython 2.4 has no wx.App.IsMainLoopRunning() method
> imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False)
> if imlr():
> wxapp.MainLoop()
>
> If I'm reading this correctly, shouldn't it be "if not imlr()"?
Yes, it should be. I'll try to code with my eyes open from now on. :-/
Ken