matplotlib-users Mailing List for matplotlib

Thanks friends from the Matplotlib and Freetype forum, 
=)
 I've succeeded to compile all per-requisites from the source and executed
the python build and install successfully under the SUSE Linux. I've
already executed a few sample cases with a Agg .png render, its working
perfectly under the s390 mainframe. 
In summary: Overall, all great support from the community, thanks. 
Claude
Benjamin Root-2 wrote:
> 
> On Thu, Sep 15, 2011 at 1:22 PM, John Hunter <jd...@gm...> wrote:
> 
>> On Thu, Sep 15, 2011 at 11:42 AM, falbriard <cl...@br...> wrote:
>> >
>> > Thanks Michael for your quick reply. I will consider use of the yum
>> tool
>> to
>> > install the per-requisite and future updates.
>> >
>> > Meanwhile I got a step forwards with help of the freetype developer
>> forum
>> > and I succeeded to build the freetype2 from the source. So I've also
>> > repeated the "python setup.py build" which gave me a new error message
>> > "cannot find -lz " . See the linker command below:
>> >
>> > g++ -pthread -shared build/temp.linux-s390x-2.6/src/ft2font.o
>> > build/temp.linux-s390x-2.6/src/mplutils.o
>> > build/temp.linux-s390x-2.6/CXX/IndirectPythonInterface.o
>> > build/temp.linux-s390x-2.6/CXX/cxx_extensions.o
>> > build/temp.linux-s390x-2.6/CXX/cxxsupport.o
>> > build/temp.linux-s390x-2.6/CXX/cxxextensions.o -L/usr/local/lib
>> > -L/usr/local/lib -L/usr/lib -L/usr/local/lib64 -L/usr/lib64
>> -L/usr/lib64
>> > -lfreetype -lz -lstdc++ -lm -lpython2.6 -o
>> > build/lib.linux-s390x-2.6/matplotlib/ft2font.so
>> >
>> /usr/lib64/gcc/s390x-suse-linux/4.3/../../../../s390x-suse-linux/bin/ld:
>> > cannot find -lz
>>
>>
>> That error means mpl could not find libz, which probably means you
>> don't have libpng installed either. mpl has a fair number of
>> dependencies. See
>>
>> http://matplotlib.sourceforge.net/users/installing.html#build-requirements
>>
>> On debian systems, there is a brilliant command
>>
>> apt-get build-dep python-matplotlib
>>
>> which will install everything you need to build mpl from source.
>> SUSE is RPM based: is there anything equivalent in rpm yum land?
>>
>>
> Yes, and it has been included in the docs for the v1.1.0 release.
> 
> You will need to install whatever package that would contain the program
> 'yum-builddep' and use the command:
> 
> yum-builddep python-matplotlib
> 
> I hope that helps!
> Ben Root
> 
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop 
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more
> affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
-- 
View this message in context: http://old.nabble.com/Problems-installing-Matplotlib-under-SUSE-SLES-11-SP1-tp32468310p32474894.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Thu, Sep 15, 2011 at 14:48, Filipe Pires Alvarenga Fernandes
<oc...@gm...> wrote:
> On Thu, Sep 15, 2011 at 14:34, John Hunter <jd...@gm...> wrote:
>> On Thu, Sep 15, 2011 at 1:31 PM, Filipe Pires Alvarenga Fernandes
>> <oc...@gm...> wrote:
>>> Hi,
>>>
>>> On SUSE you have "zypper"
>>>
>>> I'm not familiar with SUSE repos, but OpenSUSE repos do have
>>> matplotlib, just type:
>>>
>>> "sudo zypper in python-matplolib"
>>>
>>> that should install it for you.
>>
>> And if you want to build mpl from src, eg to track current
>> development, is there a way in opensuse to automatically install all
>> the build dependencies for python-matplotlib?
>>
>
> Yes, all you have to do is write a script that install all the
> depencies with "sudo zypper in ...". To get a list of the dependencies
> in "OpenSUSE names" you can check this spec file and install
> everything flagged as "BuildRequires":
>
> https://build.opensuse.org/package/view_file?file=python-matplotlib.spec&package=python-matplotlib&project=home%3Aocefpaf&srcmd5=c5a84278ace03073116b104df3e303e3
>
> However, I recommend non-developer to use a packaged version. I
> maintain a weekly git checkout of matplotlib for OpenSUSE in my home
> repo here:
> http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_11.4/
> (for 11.4)
> http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_Tumbleweed/
> (for Tumbleweed)
>
> and here is a list with all the packages in those repos if some is interested:
> https://build.opensuse.org/project/packages?project=home%3Aocefpaf
> https://build.opensuse.org/project/packages?project=home%3Aocefpaf%3AETS
>
> -Filipe.
>
Just found this script that emulates the apt build dep:
http://lilypond.org/~janneke/software/suse/zypper-build-dep
-Filipe

On Thu, Sep 15, 2011 at 14:34, John Hunter <jd...@gm...> wrote:
> On Thu, Sep 15, 2011 at 1:31 PM, Filipe Pires Alvarenga Fernandes
> <oc...@gm...> wrote:
>> Hi,
>>
>> On SUSE you have "zypper"
>>
>> I'm not familiar with SUSE repos, but OpenSUSE repos do have
>> matplotlib, just type:
>>
>> "sudo zypper in python-matplolib"
>>
>> that should install it for you.
>
> And if you want to build mpl from src, eg to track current
> development, is there a way in opensuse to automatically install all
> the build dependencies for python-matplotlib?
>
Yes, all you have to do is write a script that install all the
depencies with "sudo zypper in ...". To get a list of the dependencies
in "OpenSUSE names" you can check this spec file and install
everything flagged as "BuildRequires":
https://build.opensuse.org/package/view_file?file=python-matplotlib.spec&package=python-matplotlib&project=home%3Aocefpaf&srcmd5=c5a84278ace03073116b104df3e303e3
However, I recommend non-developer to use a packaged version. I
maintain a weekly git checkout of matplotlib for OpenSUSE in my home
repo here:
http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_11.4/
(for 11.4)
http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_Tumbleweed/
(for Tumbleweed)
and here is a list with all the packages in those repos if some is interested:
https://build.opensuse.org/project/packages?project=home%3Aocefpaf
https://build.opensuse.org/project/packages?project=home%3Aocefpaf%3AETS
-Filipe.

On Thu, Sep 15, 2011 at 1:31 PM, Filipe Pires Alvarenga Fernandes
<oc...@gm...> wrote:
> Hi,
>
> On SUSE you have "zypper"
>
> I'm not familiar with SUSE repos, but OpenSUSE repos do have
> matplotlib, just type:
>
> "sudo zypper in python-matplolib"
>
> that should install it for you.
And if you want to build mpl from src, eg to track current
development, is there a way in opensuse to automatically install all
the build dependencies for python-matplotlib?

On Thu, Sep 15, 2011 at 1:22 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Sep 15, 2011 at 11:42 AM, falbriard <cl...@br...> wrote:
> >
> > Thanks Michael for your quick reply. I will consider use of the yum tool
> to
> > install the per-requisite and future updates.
> >
> > Meanwhile I got a step forwards with help of the freetype developer
> forum
> > and I succeeded to build the freetype2 from the source. So I've also
> > repeated the "python setup.py build" which gave me a new error message
> > "cannot find -lz " . See the linker command below:
> >
> > g++ -pthread -shared build/temp.linux-s390x-2.6/src/ft2font.o
> > build/temp.linux-s390x-2.6/src/mplutils.o
> > build/temp.linux-s390x-2.6/CXX/IndirectPythonInterface.o
> > build/temp.linux-s390x-2.6/CXX/cxx_extensions.o
> > build/temp.linux-s390x-2.6/CXX/cxxsupport.o
> > build/temp.linux-s390x-2.6/CXX/cxxextensions.o -L/usr/local/lib
> > -L/usr/local/lib -L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -L/usr/lib64
> > -lfreetype -lz -lstdc++ -lm -lpython2.6 -o
> > build/lib.linux-s390x-2.6/matplotlib/ft2font.so
> > /usr/lib64/gcc/s390x-suse-linux/4.3/../../../../s390x-suse-linux/bin/ld:
> > cannot find -lz
>
>
> That error means mpl could not find libz, which probably means you
> don't have libpng installed either. mpl has a fair number of
> dependencies. See
>
> http://matplotlib.sourceforge.net/users/installing.html#build-requirements
>
> On debian systems, there is a brilliant command
>
> apt-get build-dep python-matplotlib
>
> which will install everything you need to build mpl from source.
> SUSE is RPM based: is there anything equivalent in rpm yum land?
>
>
Yes, and it has been included in the docs for the v1.1.0 release.
You will need to install whatever package that would contain the program
'yum-builddep' and use the command:
yum-builddep python-matplotlib
I hope that helps!
Ben Root

Hi,
On SUSE you have "zypper"
I'm not familiar with SUSE repos, but OpenSUSE repos do have
matplotlib, just type:
"sudo zypper in python-matplolib"
that should install it for you.
-Filipe
On Thu, Sep 15, 2011 at 14:22, John Hunter <jd...@gm...> wrote:
> On Thu, Sep 15, 2011 at 11:42 AM, falbriard <cl...@br...> wrote:
>>
>> Thanks Michael for your quick reply. I will consider use of the yum tool to
>> install the per-requisite and future updates.
>>
>> Meanwhile I got a step forwards with help of the freetype developer forum
>> and I succeeded to build the freetype2 from the source. So I've also
>> repeated the "python setup.py build" which gave me a new error message
>> "cannot find -lz " . See the linker command below:
>>
>> g++ -pthread -shared build/temp.linux-s390x-2.6/src/ft2font.o
>> build/temp.linux-s390x-2.6/src/mplutils.o
>> build/temp.linux-s390x-2.6/CXX/IndirectPythonInterface.o
>> build/temp.linux-s390x-2.6/CXX/cxx_extensions.o
>> build/temp.linux-s390x-2.6/CXX/cxxsupport.o
>> build/temp.linux-s390x-2.6/CXX/cxxextensions.o -L/usr/local/lib
>> -L/usr/local/lib -L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -L/usr/lib64
>> -lfreetype -lz -lstdc++ -lm -lpython2.6 -o
>> build/lib.linux-s390x-2.6/matplotlib/ft2font.so
>> /usr/lib64/gcc/s390x-suse-linux/4.3/../../../../s390x-suse-linux/bin/ld:
>> cannot find -lz
>
>
> That error means mpl could not find libz, which probably means you
> don't have libpng installed either. mpl has a fair number of
> dependencies. See
>
> http://matplotlib.sourceforge.net/users/installing.html#build-requirements
>
> On debian systems, there is a brilliant command
>
> apt-get build-dep python-matplotlib
>
> which will install everything you need to build mpl from source.
> SUSE is RPM based: is there anything equivalent in rpm yum land?
>
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops?  How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Thu, Sep 15, 2011 at 11:42 AM, falbriard <cl...@br...> wrote:
>
> Thanks Michael for your quick reply. I will consider use of the yum tool to
> install the per-requisite and future updates.
>
> Meanwhile I got a step forwards with help of the freetype developer forum
> and I succeeded to build the freetype2 from the source. So I've also
> repeated the "python setup.py build" which gave me a new error message
> "cannot find -lz " . See the linker command below:
>
> g++ -pthread -shared build/temp.linux-s390x-2.6/src/ft2font.o
> build/temp.linux-s390x-2.6/src/mplutils.o
> build/temp.linux-s390x-2.6/CXX/IndirectPythonInterface.o
> build/temp.linux-s390x-2.6/CXX/cxx_extensions.o
> build/temp.linux-s390x-2.6/CXX/cxxsupport.o
> build/temp.linux-s390x-2.6/CXX/cxxextensions.o -L/usr/local/lib
> -L/usr/local/lib -L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -L/usr/lib64
> -lfreetype -lz -lstdc++ -lm -lpython2.6 -o
> build/lib.linux-s390x-2.6/matplotlib/ft2font.so
> /usr/lib64/gcc/s390x-suse-linux/4.3/../../../../s390x-suse-linux/bin/ld:
> cannot find -lz
That error means mpl could not find libz, which probably means you
don't have libpng installed either. mpl has a fair number of
dependencies. See
http://matplotlib.sourceforge.net/users/installing.html#build-requirements
On debian systems, there is a brilliant command
apt-get build-dep python-matplotlib
which will install everything you need to build mpl from source.
SUSE is RPM based: is there anything equivalent in rpm yum land?

Hi all,
what are the differences between the griddata 
implementations in matplotlib and scipy, i.e.
from scipy.interpolate import griddata
and
from matplotlib.mlab import griddata
Is the Shepard algorithm available in matplotlib/scipy ?
Nils
Reference:
Robert J. Renka
Algorithm 790: CSHEP2D: Cubic Shepard Method for Bivariate
Interpolation of Scattered Data.
ACM Transactions on Mathematical Software, Vol. 25 No. 1
(1999) pp. 70-73

Thanks. With this explanation I was able to get things to work.
On Sep 14, 2011, at 12:41 PM, Benjamin Root wrote:
> On Wed, Sep 14, 2011 at 2:17 PM, Raymond Hawkins <rha...@ea...> wrote:
> I'm getting odd behavior when I try to use fmin and pylab in the same program. The issue is illustrated in the code snippet below. As written, fmin won't work: the "print xopt" simply returns the contents of x0 as assigned in the line before fmin. If the "from pylab import *" line is commented out, however, then fmin runs as expected.
> 
> I'm running python 2.7.2 on a MacBook Pro with a recent install & upgrade of scipy and matplotlib via macports. Any suggestions would be appreciated.
> 
> -------------------------------------
> 
> #!/opt/local/bin/python
> 
> from scipy import *
> from scipy.optimize import fmin
> import matplotlib
> matplotlib.use('MacOSX')
> from pylab import *
> 
> def rosen(x): # The Rosenbrock function
> return sum(100.0*(x[1:]-x[:-1]**2.0)**2.0 + (1-x[:-1])**2.0)
> 
> x0 = [1.3, 0.7, 0.8, 1.9, 1.2]
> 
> xopt = fmin(rosen, x0)
> 
> print xopt
> 
> Because pylab brings the numpy namespace into the current namespace, numpy's fmin is imported and replaces the previously def'ed fmin from scipy.optimize. Numpy's fmin function is completely different from scipy's fmin. Try putting the "from scipy.optimize import fmin" after the pylab import line. Or, do something like "from scipy.optimize import fmin as fminimize" to avoid name collision.
> 
> I hope that helps.
> 
> Ben Root
> 

Thanks. Removing the import of pylab and adding your suggested "import matplotlib.pyplot as plt" worked.
On Sep 14, 2011, at 12:46 PM, Eric Firing wrote:
> On 09/14/2011 09:17 AM, Raymond Hawkins wrote:
>> I'm getting odd behavior when I try to use fmin and pylab in the same program. The issue is illustrated in the code snippet below. As written, fmin won't work: the "print xopt" simply returns the contents of x0 as assigned in the line before fmin. If the "from pylab import *" line is commented out, however, then fmin runs as expected.
>> 
> 
> This is a good illustration of why "from package_x import *" is so 
> strongly discouraged; it is throwing away one of the most important 
> features of python--the default separation of packages into their own 
> name spaces.
> 
> The only exception with respect to pylab is that for quick and dirty 
> interactive use, particularly within ipython, it is sometimes worthwhile 
> to sacrifice some name space separation for typing speed. But in a 
> script that imports from more than one external package, it is best to 
> always use explicit imports in some form.
> 
> The preferred idiom is to avoid importing pylab at all in scripts; 
> instead, do this:
> 
> import numpy as np
> import matplotlib.pyplot as plt
> 
> Eric
> 
>> I'm running python 2.7.2 on a MacBook Pro with a recent install& upgrade of scipy and matplotlib via macports. Any suggestions would be appreciated.
>> 
>> -------------------------------------
>> 
>> #!/opt/local/bin/python
>> 
>> from scipy import *
>> from scipy.optimize import fmin
>> import matplotlib
>> matplotlib.use('MacOSX')
>> from pylab import *
>> 
>> def rosen(x): # The Rosenbrock function
>> return sum(100.0*(x[1:]-x[:-1]**2.0)**2.0 + (1-x[:-1])**2.0)
>> 
>> x0 = [1.3, 0.7, 0.8, 1.9, 1.2]
>> 
>> xopt = fmin(rosen, x0)
>> 
>> print xopt
>> ------------------------------------------------------------------------------
>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>> Learn about the latest advances in developing for the
>> BlackBerry® mobile platform with sessions, labs& more.
>> See new tools and technologies. Register for BlackBerry® DevCon today!
>> http://p.sf.net/sfu/rim-devcon-copy1
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the 
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Thanks Michael for your quick reply. I will consider use of the yum tool to
install the per-requisite and future updates. 
 Meanwhile I got a step forwards with help of the freetype developer forum
and I succeeded to build the freetype2 from the source. So I've also
repeated the "python setup.py build" which gave me a new error message
"cannot find -lz " . See the linker command below: 
g++ -pthread -shared build/temp.linux-s390x-2.6/src/ft2font.o
build/temp.linux-s390x-2.6/src/mplutils.o
build/temp.linux-s390x-2.6/CXX/IndirectPythonInterface.o
build/temp.linux-s390x-2.6/CXX/cxx_extensions.o
build/temp.linux-s390x-2.6/CXX/cxxsupport.o
build/temp.linux-s390x-2.6/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/local/lib -L/usr/lib -L/usr/local/lib64 -L/usr/lib64 -L/usr/lib64
-lfreetype -lz -lstdc++ -lm -lpython2.6 -o
build/lib.linux-s390x-2.6/matplotlib/ft2font.so
/usr/lib64/gcc/s390x-suse-linux/4.3/../../../../s390x-suse-linux/bin/ld:
cannot find -lz
 
Hope somebody from this forum can give me some insights about this
dependency, to complete the matplotlib install process.
Thanks in advance for your support. 
Regards, 
Claude 
Michael Droettboom-3 wrote:
> 
> I wouldn't recommend trying to build freetype from source. Have you 
> installed the freetype development package? I'm not familiar with SuSE, 
> but on RedHat/Fedora this would be accomplished by (as root) "yum 
> install freetype2-dev" and on Debian/Ubuntu "apt-get install 
> freetype2-devel".
> 
> Mike
> 
> On 09/14/2011 08:23 PM, falbriard wrote:
>> Having issues with installing the matplotlib package under Linux SUSE
>> SLES 11
>> SP1 (s390):
>>
>> The original distribution gcc throws an error:
>> "src/ft2font.h:14:22: error: ft2build.h: No such file or directory"
>>
>> when adding the file ft2build.h the linkage process stops at this error:
>> G++ cannot find -lfreetype
>>
>> When trying to manually install the latest Freetype2 package, I get an
>> error
>> when using the package build commands, both at the "make" and "jam"
>>
>> Errors:
>> -------
>> error at make command:
>> zbra:/opt/python/freetype2/freetype-2.4.6 # make
>> config.mk:25: builds/unix/unix-def.mk: No such file or directory
>> config.mk:26: builds/unix/unix-cc.mk: No such file or directory
>> make: *** No rule to make target `builds/unix/unix-cc.mk'. Stop.
>>
>>
>> error at jam command
>> zbra:/opt/python/freetype2/freetype-2.4.6 # jam install
>> don't know how to make install
>> ...found 1 target(s)...
>> ...can't find 1 target(s)...
>>
>>
>> Thanks in advance for any hints,
>> Claude
> 
> 
> ------------------------------------------------------------------------------
> Doing More with Less: The Next Generation Virtual Desktop 
> What are the key obstacles that have prevented many mid-market businesses
> from deploying virtual desktops? How do next-generation virtual desktops
> provide companies an easier-to-deploy, easier-to-manage and more
> affordable
> virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
-- 
View this message in context: http://old.nabble.com/Problems-installing-Matplotlib-under-SUSE-SLES-11-SP1-tp32468310p32473135.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Sep 14, 2011, at 4:04 PM, Jeffrey Blackburne wrote:
> I am trying to create a hatched region, with a "diagonal lines" hatch
> pattern. When using the PS backend, the hatch lines come out very
> narrow. Is there a way to increase the thickness of the hatch lines?
> I am using mpl version 1.0.1.
Ok, further searching led to an answer for the PDF backend. The 
linewidth is hard-coded to 0.1pt.
http://www.mail-archive.com/mat...@li.../ 
msg20873.html
I assume it is similar for PS, because the output looks the same when 
I use both.
Also, it seems there is an open issue on github (for the PDF case 
anyway):
https://github.com/matplotlib/matplotlib/issues/235
For now, I will just use a solid color fill instead, and await an 
updated hatch capability!
Thanks,
Jeff

I was able to confirm this bug with 1.0.1, but it has already been fixed 
in git master. This fix should make it into the next release.
I used "git bisect" to track down the point at which it was fixed and 
turned up this:
 
https://github.com/matplotlib/matplotlib/commit/6fe5fa03e8608949cb08a485a4d6adf9247a5ffb
Unfortunately, that won't apply cleanly to 1.0.1, so I can't recommend a 
quick fix other than updating to git master.
Mike
On 09/15/2011 05:03 AM, Eric O LEBIGOT (EOL) wrote:
> I had a closer look at an issue raised previously
> (http://old.nabble.com/can%27t-output-emf-pdf-eps-figure-file-corrently-with-my-dataset.-to31104695.html#a31107307),
> because I found out where the problem lies: when plotting a figure in log
> scale with some null values, screen plots display fine (Mac OS X backend);
> however, when trying to save the figure (with savefig) to PDF, a "Path lacks
> initial MOVETO" exception is raised (it looks like this may be related to
> the way masked values are handled by both backends).
>
> It would be better if Matplotlib's backends were consistent, here (i.e. if
> it failed both on screen and when generating the PDF, or if it did not fail
> at all).
>
> I attach a slightly modified version of the original program:
> http://old.nabble.com/file/p32470066/t.py t.py . Commenting out the
> savefig() call makes the program work nicely (Mac OS X backend, MacPort's
> Matplotlib 1.0.1).

On Fri, Sep 9, 2011 at 5:04 PM, Matt Earnshaw <ma...@ea...> wrote:
> Hi all,
>
> I am encountering a memory leak type issue when running the following,
> for example.
>
> http://codepad.org/TNuCLT3k
>
> Matplotlib version: 0.99.3
> PyQt4 Version: 4.8.5
>
> I found a thread in the archive relating to this issue which supposedly
> disappeared upon updating to PyQt 4.8.4 (I trust it would not have been
> reintroduced in going to .5).
>
> Can someone confirm or deny replication of this issue with their setup
> and/or offer a solution?
This doesn't look like a leak, it looks like code error. You are
creating unlimited numbers of figures w/o closing the old ones. And
the use of pyplot with GUI code is not supported. You need to use the
"embedding_in*qt*.py approach. See the examples at
http://matplotlib.sourceforge.net/examples/user_interfaces/index.html

John Hunter-4 wrote:
> 
> On Thu, Sep 15, 2011 at 4:03 AM, Eric O LEBIGOT (EOL)
> <Eri...@no...> wrote:
> 
>> It would be better if Matplotlib's backends were consistent, here (i.e.
>> if
>> it failed both on screen and when generating the PDF, or if it did not
>> fail
>> at all).
>>
>> I attach a slightly modified version of the original program:
>> http://old.nabble.com/file/p32470066/t.py t.py . Commenting out the
>> savefig() call makes the program work nicely (Mac OS X backend, MacPort's
>> Matplotlib 1.0.1).
> 
> I can replicate the bug on the 1.0.1 release branch but not on master,
> so it appears to have been fixed, but I am not sure which commit is
> responsible for the fix. Look for the fix in the next release, or
> upgrade from github if you need a fix sooner.
> 
> Thanks for the report,
> JDH
> 
Thanks, John. Looking forward to the next release. :)
-- 
View this message in context: http://old.nabble.com/PDF-%28but-not-screen%29-output-raises-%22Path-lacks-initial-MOVETO%22-tp32470066p32472380.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I wouldn't recommend trying to build freetype from source. Have you 
installed the freetype development package? I'm not familiar with SuSE, 
but on RedHat/Fedora this would be accomplished by (as root) "yum 
install freetype2-dev" and on Debian/Ubuntu "apt-get install 
freetype2-devel".
Mike
On 09/14/2011 08:23 PM, falbriard wrote:
> Having issues with installing the matplotlib package under Linux SUSE SLES 11
> SP1 (s390):
>
> The original distribution gcc throws an error:
> "src/ft2font.h:14:22: error: ft2build.h: No such file or directory"
>
> when adding the file ft2build.h the linkage process stops at this error:
> G++ cannot find -lfreetype
>
> When trying to manually install the latest Freetype2 package, I get an error
> when using the package build commands, both at the "make" and "jam"
>
> Errors:
> -------
> error at make command:
> zbra:/opt/python/freetype2/freetype-2.4.6 # make
> config.mk:25: builds/unix/unix-def.mk: No such file or directory
> config.mk:26: builds/unix/unix-cc.mk: No such file or directory
> make: *** No rule to make target `builds/unix/unix-cc.mk'. Stop.
>
>
> error at jam command
> zbra:/opt/python/freetype2/freetype-2.4.6 # jam install
> don't know how to make install
> ...found 1 target(s)...
> ...can't find 1 target(s)...
>
>
> Thanks in advance for any hints,
> Claude

Confirmed with:
 PyQt4 4.8.3
 Matplotlib 1.1.0
Not sure what the cause is though.
Keith
On Fri, Sep 9, 2011 at 6:04 PM, Matt Earnshaw <ma...@ea...> wrote:
> Hi all,
>
> I am encountering a memory leak type issue when running the following,
> for example.
>
> http://codepad.o rrg/TNuCLT3k <http://codepad.org/TNuCLT3k>
>
> Matplotlib version: 0.99.3
> PyQt4 Version: 4.8.5
>
> I found a thread in the archive relating to this issue which supposedly
> disappeared upon updating to PyQt 4.8.4 (I trust it would not have been
> reintroduced in going to .5).
>
> Can someone confirm or deny replication of this issue with their setup
> and/or offer a solution?
>
> Thanks very much
> Matt Earnshaw
>
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Thu, Sep 15, 2011 at 4:03 AM, Eric O LEBIGOT (EOL)
<Eri...@no...> wrote:
> It would be better if Matplotlib's backends were consistent, here (i.e. if
> it failed both on screen and when generating the PDF, or if it did not fail
> at all).
>
> I attach a slightly modified version of the original program:
> http://old.nabble.com/file/p32470066/t.py t.py . Commenting out the
> savefig() call makes the program work nicely (Mac OS X backend, MacPort's
> Matplotlib 1.0.1).
I can replicate the bug on the 1.0.1 release branch but not on master,
so it appears to have been fixed, but I am not sure which commit is
responsible for the fix. Look for the fix in the next release, or
upgrade from github if you need a fix sooner.
Thanks for the report,
JDH

On Thu, Sep 15, 2011 at 7:12 AM, Nils Wagner
<nw...@ia...>wrote:
> Hi all,
>
> I am looking for a simple method to generate various
> colours (n > 15, n denotes the number of colours) for a
> stacked bar plot.
>
> Any pointer would be appreciated.
>
> The example
> http://matplotlib.sourceforge.net/examples/pylab_examples/table_demo.html
> generates pastel colours. However the difference between
> the different colors decreases drastically.
>
You might try using one or more of the default
colormaps<http://matplotlib.sourceforge.net/examples/pylab_examples/show_colormaps.html>to
generate colors. For example:
>>> for n in np.linspace(0, 1, 20):
>>> plt.plot(n, 0, 'o', mfc=plt.cm.Set1(n))
will plot 20 points in a line with a different color for each dot.
Nevertheless, some colors are difficult to differentiate. Instead of
grabbing all your colors from one colormap you could grab the first 10 from
a pastel colormap (e.g. 'Set3') and then the next 10 from a dark colormap
(e.g. 'Dark2') and maybe even some more from a bright colormap (e.g.
'spectral').
You'll probably have to tweak these colormaps before they are properly
differentiated (i.e. you might not be able to get away with evenly-spaced
indexes into the colormap), but something like this should work.
Best,
-Tony
(Sorry for the duplicate email, Nils, but I forgot to reply all).

I'm wondering if there is some way to do cross hatching as a way to fill
contours rather than colors (using contourf). The only references to
cross hatching I see in the documentation are for patches type objects.
As far as I can tell, contour and contourf return objects of their own
type (contour.QuadContourSet) that do not have hatch as an attribute.
If it's not possible currently, how hard would it be to add that
capability to contourf? What approach would you recommend?
Regards,
Jon

Hi all,
I am looking for a simple method to generate various 
colours (n > 15, n denotes the number of colours) for a 
stacked bar plot.
Any pointer would be appreciated.
The example 
http://matplotlib.sourceforge.net/examples/pylab_examples/table_demo.html
generates pastel colours. However the difference between 
the different colors decreases drastically.
Nils
 

I had a closer look at an issue raised previously
(http://old.nabble.com/can%27t-output-emf-pdf-eps-figure-file-corrently-with-my-dataset.-to31104695.html#a31107307),
because I found out where the problem lies: when plotting a figure in log
scale with some null values, screen plots display fine (Mac OS X backend);
however, when trying to save the figure (with savefig) to PDF, a "Path lacks
initial MOVETO" exception is raised (it looks like this may be related to
the way masked values are handled by both backends).
It would be better if Matplotlib's backends were consistent, here (i.e. if
it failed both on screen and when generating the PDF, or if it did not fail
at all).
I attach a slightly modified version of the original program: 
http://old.nabble.com/file/p32470066/t.py t.py . Commenting out the
savefig() call makes the program work nicely (Mac OS X backend, MacPort's
Matplotlib 1.0.1).
-- 
View this message in context: http://old.nabble.com/PDF-%28but-not-screen%29-output-raises-%22Path-lacks-initial-MOVETO%22-tp32470066p32470066.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

You are correct JJ; the annotation_clip=False attribute was exactly
what I was after, but somehow missed it in the docs :(.
On Wed, Sep 14, 2011 at 9:09 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Mon, Sep 12, 2011 at 3:20 AM, Daniel Hyams <dh...@gm...> wrote:
>> I would suggest the following modification to Annotation.draw in
>> text.py. All it does is set a clip box so that the annotation and
>> arrow is still drawn, but the arrow is clipped at the axes boundary.
>> It is a much nicer effect than the annotation disappearing. I have
>> made this modification in my source locally, and it works very well,
>> but I thought I would suggest here for inclusion into the main code
>> base.
>>
>
> Can you explain more explicitly why you think this behavior is better?
> For example, what is the point of annotating something if that
> something is not visible?
> Also, annotating texts are often placed outside of axes area. I don't
> think clipping out the arrow is a good idea in this case.
>
> Just in case, this is just a default behavior. You can override this
> behavior without changing the mpl source code.
>
> Regards,
>
> -JJ
>
--
Daniel Hyams
dh...@gm...

On Mon, Sep 12, 2011 at 3:20 AM, Daniel Hyams <dh...@gm...> wrote:
> I would suggest the following modification to Annotation.draw in
> text.py. All it does is set a clip box so that the annotation and
> arrow is still drawn, but the arrow is clipped at the axes boundary.
> It is a much nicer effect than the annotation disappearing. I have
> made this modification in my source locally, and it works very well,
> but I thought I would suggest here for inclusion into the main code
> base.
>
Can you explain more explicitly why you think this behavior is better?
For example, what is the point of annotating something if that
something is not visible?
Also, annotating texts are often placed outside of axes area. I don't
think clipping out the arrow is a good idea in this case.
Just in case, this is just a default behavior. You can override this
behavior without changing the mpl source code.
Regards,
-JJ

On Thu, Sep 15, 2011 at 5:08 AM, Youngung Jeong
<you...@gm...> wrote:
> but since contour function does not plot on the polar coordinate system
I think this is not True, but I may misunderstood you. Can you post an
example that does not work? Here is a simple example that shows it
does work. But I hardly use polar coordinate, and my example could be
too simple.
ax = subplot(111, polar=True)
aa = np.indices((10,10))
x = np.linspace(0., np.pi*2, 10)
y = np.linspace(0., 10, 10)
ax.pcolormesh(x, y, aa[0], cmap="gray")
ax.contour(x, y, aa[0])
Both pcolormesh and contour gives a consistent result.
However, I think, while the resulting contour lines are drawn in polar
coordinate system, the actual contouring is done in rectlinear
cooridinate system. So there may be some caveats.
Regards,
-JJ