matplotlib-users Mailing List for matplotlib

Hi all,
I'm producing a plot with 11 lines, each of which must have a legend 
entry. I'd also like the plot to be wider than it is high.
Since I want a wide plot, I'd prefer to have my legend labels aligned in 
an array, rather than all 11 on top of each other. (So I can put them 
across the bottom of the figure.) Something like:
label1 label4 label7 label10
label2 label5 label8 label11
label3 label6 label9
Can the current matplotlib do this? If so, how?
Thanks,
Ryan
-- 
Ryan Gutenkunst |
Cornell LASSP | "It is not the mountain
 | we conquer but ourselves."
Clark 535 / (607)227-7914 | -- Sir Edmund Hillary
AIM: JepettoRNG |
 http://www.physics.cornell.edu/~rgutenkunst/

Hi, Hardip, try having a look at these instructions:
http://www.scipy.org/wikis/topical_software/CompilingMatPlotLibOnSolaris10
Hope this helps.
E
On Thu, 6 Oct 2005, Hardip Sanghera wrote:
> Date: Thu, 6 Oct 2005 10:19:29 +0100 (BST)
> From: Hardip Sanghera <hs...@as...>
> To: mat...@li...
> Subject: [Matplotlib-users] Cannot install matplotlib on Solaris 10
> 
> Hi,
> I cannot get matplotlib to install on my Solaris 10 platform, and would
> really appreciate some help.
> 
> I've installed the latest version of python from a Solaris 10 package:
> 
> % /usr/local/bin/python -V
> Python 2.4.2
> 
> Added various modules including Numarray and numeric:
> 
> % /usr/local/bin/python
> Python 2.4.2 (#1, Oct 3 2005, 01:55:05)
> [GCC 3.3.2] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numarray
> >>> import Numeric
> >>> ^D
> 
> Then downloading and unpacking the latest version, matplotlib-0.84
> However, it doesn't matter which version of gcc that I use with
> 
> setenv CC gcc
> 
> where gcc can be either the version that comes with Solaris 10:
> 
> % /usr/sfw/bin/gcc -v
> gcc version 3.4.3
> 
> % setenv CC /usr/sfw/bin/gcc
> % /usr/local/bin/python setup.py build
> 
> GTK requires pygtk
> GTKAgg requires pygtk
> running build
> running build_py
> creating build
> creating build/lib.solaris-2.10-sun4u-2.4
> copying lib/pylab.py -> build/lib.solaris-2.10-sun4u-2.4
> creating build/lib.solaris-2.10-sun4u-2.4/matplotlib
> copying lib/matplotlib/__init__.py ->
> build/lib.solaris-2.10-sun4u-2.4/matplotlib
> copying lib/matplotlib/_contour.py ->
> build/lib.solaris-2.10-sun4u-2.4/matplotlib
> ...
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h: In static member function `static wchar_t*
> std::char_traits<wchar_t>::move(wchar_t*, cons
> t wchar_t*, size_t)':
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h:336: error: `wmemmove' undeclared (first use this function)
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h: In static member function `static wchar_t*
> std::char_traits<wchar_t>::copy(wchar_t*, cons
> t wchar_t*, size_t)':
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h:340: error: `wmemcpy' undeclared (first use this function)
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h: In static member function `static wchar_t*
> std::char_traits<wchar_t>::assign(wchar_t*, si
> ze_t, wchar_t)':
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h:344: error: `wmemset' undeclared (first use this function)
> error: command '/usr/sfw/bin/gcc' failed with exit status 1
> 
> (whole message file is the first attachtment)
> 
> or my own built version:
> 
> /usr/local/bin/gcc -v
> gcc version 3.3.2
> 
> which matches the version that python itself was built with:
> 
> % setenv CC /usr/local/bin/gcc
> % /usr/local/bin/python setup.py build
> 
> GTK requires pygtk
> GTKAgg requires pygtk
> running build
> running build_py
> creating build
> creating build/lib.solaris-2.10-sun4u-2.4
> copying lib/pylab.py -> build/lib.solaris-2.10-sun4u-2.4
> creating build/lib.solaris-2.10-sun4u-2.4/matplotlib
> ...
> /usr/include/pthread.h:305: error: parse error before `)' token
> /usr/include/pthread.h:306: error: `pthread_barrierattr_t' was not
> declared in
> this scope
> /usr/include/pthread.h:306: error: parse error before `,' token
> /usr/include/pthread.h:308: error: parse error before `*' token
> /usr/include/pthread.h:309: error: `pthread_barrier_t' was not declared in
> this
> scope
> /usr/include/pthread.h:309: error: parse error before `,' token
> /usr/include/pthread.h:311: error: `pthread_barrier_t' was not declared in
> this
> scope
> /usr/include/pthread.h:311: error: parse error before `)' token
> /usr/include/pthread.h:312: error: `pthread_barrier_t' was not declared in
> this
> scope
> /usr/include/pthread.h:312: error: parse error before `)' token
> error: command '/usr/local/bin/gcc' failed with exit status 1
> 
> (whole message file is the second attachtment)
> 
> Any help would really be appreciated as I need matplotlib to install.
> 
> cheers,
> hardip
> 
> -------------------------------------------------------------------------------
> 
> Hardip S. Sanghera (hs...@as...)
> 
> Institute of Astronomy Phone (office): 44 (0)1223 766663
> Madingley Road Fax: 44 (0)1223 337523
> Cambridge CB3 0HA
> United Kingdom

>>>>> "Martin" == Martin Richter <law...@gm...> writes:
 Martin> Hello everyone, Hello John,
 Martin> I would like to ask you (right before I'll mess everything
 Martin> up ;) if all this at least could work: What I would try
 Martin> for unification is writing the dictionary 'markerd' in
 Martin> lines.py (I'd prefer it right in front of 'class Line2D'
 Martin> as global - but there it isn't readable for a program
 Martin> later, isn't it?) and change the functions a bit like: def
 Martin> _make_triangle_down(size): return reshape([[0, -size,
Hi Martin,
Sorry for the delay getting back to you.
Perhaps the best approach is to predefine some paths in a new module,
eg data.py and define your path dictionary like so
 from matplotlib import agg
 markerd = {}
 # triangle up
 path = agg.path_storage()
 path.move_to(0, 1.0)
 path.line_to(-1.0, -1.0)
 path.line_to(1.0, -1.0)
 path.end_poly()
 markerd['^'] = path
 # square
 path = agg.path_storage()
 path.move_to(-1.0, -1.0)
 path.line_to(-1.0, 1.0)
 path.line_to(1.0, 1.0)
 path.line_to(1.0, -1.0)
 path.end_poly()
 markerd['s'] = path
We should think about what property of the marker should be conserved
(radius in points, area, area of circumscribed circle), because I
don't think we're terribly consistent on that one currently. In the
current implementation, the markersize of the triangle and square
gives the side, for the circle it gives the diameter. I'm not sure
what the right answer is here, but while you are doing this
refactoring it would be good to rationalize this and document any
changes in API_CHANGES.
In lines.py you could transform this path to scale it to the requested
size; something like
 def _draw_square(self, renderer, gc, xt, yt):
 side = renderer.points_to_pixels(self._markersize)
 s = side*0.5
 rgbFace = self._get_rgb_face()
 if self._newstyle:
 path = markerd['s']
 scale = agg.trans_affine_scaling(s,s) 
 transpath = agg.conv_transform_path(path, scale)
 renderer.draw_markers(gc, transpath, rgbFace, xt, yt, self._transform)
 
We would then need to modify renderer.draw_markers to take a
transformed path "transpath" rather than a path but this would be easy
-- I'm including a modified src/_backend_agg.cpp
RendererAgg::draw_markers function below if you want to go this route.
For code that doesn't want to use the path object, it is easy to
extract the moveto/lineto command as well as the vertices like so 
for i in range(path.total_vertices()):
 command, x, y = path.vertex(i)
 print command, x, y
With a little thought and care, you should be able to do away with all
the _draw_square, _draw_triangle, etc, in Line2D and replace them with
a single _draw_path, eg
 def _draw_path(self, renderer, gc, path, xt, yt):
 s = renderer.points_to_pixels(self._markersize)
 scale = agg.trans_affine_scaling(s,s) 
 transpath = agg.conv_transform_path(path, translation)
 renderer.draw_markers(gc, transpath, rgbFace, xt, yt, self._transform)
where the calling function pulls the path out of the dict.
Another advantage of this approach is that it could supports arbitrary
paths (including splines) and user extensible markers. Eg, the user
should be able to do
 markerd['somekey'] = somepath
and then be able to call 
 plot(rand(N), marker='somekey')
and have everything work automagically -- your task is growing :-)
Seriously, though, I think this would be a very nice addition, and not
too much work.
 Martin> Another question would be: Are those new for-loops in
 Martin> _draw_marker() too annoying (in the sense of speed)? (I
 Martin> quess they are vital for the _make_triangle_down()-like
I don't think the for loop is a problem because it is one per line
object, so as long as you don't create a ton of separate lines, you'll
be OK.
JDH
Here is the modified code from _backend_agg.cpp you will need
Py::Object
RendererAgg::draw_markers(const Py::Tuple& args) {
 //_draw_markers_cache(gc, path, rgbFace, xo, yo, transform)
 theRasterizer->reset_clipping();
 
 _VERBOSE("RendererAgg::_draw_markers");
 args.verify_length(6); 
 
 GCAgg gc = GCAgg(args[0], dpi);
 agg::conv_transform<agg::path_storage> *ppath;
 swig_type_info * descr = SWIG_TypeQuery("agg.conv_transform<agg::path_storage> *"); 
 assert(descr);
 if (SWIG_ConvertPtr(args[1].ptr(),(void **)(&ppath), descr, 0) == -1) 
 throw Py::TypeError("Could not convert agg.conv_transform<agg::path_storage>");
 facepair_t face = _get_rgba_face(args[2], gc.alpha);
 Py::Object xo = args[3];
 Py::Object yo = args[4];
 
 PyArrayObject *xa = (PyArrayObject *) PyArray_ContiguousFromObject(xo.ptr(), PyArray_DOUBLE, 1, 1); 
 
 if (xa==NULL) 
 throw Py::TypeError("RendererAgg::_draw_markers_cache expected numerix array");
 
 
 PyArrayObject *ya = (PyArrayObject *) PyArray_ContiguousFromObject(yo.ptr(), PyArray_DOUBLE, 1, 1); 
 
 if (ya==NULL) 
 throw Py::TypeError("RendererAgg::_draw_markers_cache expected numerix array");
 
 Transformation* mpltransform = static_cast<Transformation*>(args[5].ptr());
 
 double a, b, c, d, tx, ty;
 try {
 mpltransform->affine_params_api(&a, &b, &c, &d, &tx, &ty);
 }
 catch(...) {
 throw Py::ValueError("Domain error on affine_params_api in RendererAgg::_draw_markers_cache"); 
 }
 
 agg::trans_affine xytrans = agg::trans_affine(a,b,c,d,tx,ty); 
 
 size_t Nx = xa->dimensions[0];
 size_t Ny = ya->dimensions[0];
 
 if (Nx!=Ny) 
 throw Py::ValueError(Printf("x and y must be equal length arrays; found %d and %d", Nx, Ny).str());
 
 
 double heightd = double(height); 
 ppath->rewind(0);
 //ppath->flip_y(0,0);
 //typedef agg::conv_curve<agg::path_storage> curve_t;
 typedef agg::conv_curve<agg::conv_transform<agg::path_storage> > curve_t;
 curve_t curve(*ppath);
 //maxim's suggestions for cached scanlines
 agg::scanline_storage_aa8 scanlines; 
 theRasterizer->reset();
 agg::int8u* fillCache = NULL;
 unsigned fillSize = 0;
 if (face.first) {
 theRasterizer->add_path(curve);
 agg::render_scanlines(*theRasterizer, *slineP8, scanlines); 
 fillSize = scanlines.byte_size();
 fillCache = new agg::int8u[fillSize]; // or any container
 scanlines.serialize(fillCache);
 }
 
 agg::conv_stroke<curve_t> stroke(curve);
 stroke.width(gc.linewidth);
 stroke.line_cap(gc.cap);
 stroke.line_join(gc.join); 
 theRasterizer->reset();
 theRasterizer->add_path(stroke);
 agg::render_scanlines(*theRasterizer, *slineP8, scanlines); 
 unsigned strokeSize = scanlines.byte_size();
 agg::int8u* strokeCache = new agg::int8u[strokeSize]; // or any container
 scanlines.serialize(strokeCache);
 theRasterizer->reset_clipping();
 
 if (gc.cliprect==NULL) { 
 rendererBase->reset_clipping(true); 
 }
 else {
 int l = (int)(gc.cliprect[0]) ; 
 int b = (int)(gc.cliprect[1]) ; 
 int w = (int)(gc.cliprect[2]) ; 
 int h = (int)(gc.cliprect[3]) ; 
 rendererBase->clip_box(l, height-(b+h),l+w, height-b);
 }
 double thisx, thisy;
 for (size_t i=0; i<Nx; i++) {
 thisx = *(double *)(xa->data + i*xa->strides[0]);
 thisy = *(double *)(ya->data + i*ya->strides[0]);
 
 if (mpltransform->need_nonlinear_api())
 try { 
	mpltransform->nonlinear_only_api(&thisx, &thisy);
 }
 catch(...) {
	continue;
 }
 
 xytrans.transform(&thisx, &thisy);
 thisy = heightd - thisy; //flipy
 thisx = (int)thisx + 0.5;
 thisy = (int)thisy + 0.5;
 
 agg::serialized_scanlines_adaptor_aa8 sa;
 agg::serialized_scanlines_adaptor_aa8::embedded_scanline sl;
 
 if (face.first) {
 //render the fill
 sa.init(fillCache, fillSize, thisx, thisy);
 rendererAA->color(face.second); 
 agg::render_scanlines(sa, sl, *rendererAA);
 }
 
 //render the stroke
 sa.init(strokeCache, strokeSize, thisx, thisy);
 rendererAA->color(gc.color); 
 agg::render_scanlines(sa, sl, *rendererAA);
 
 } //for each marker 
 Py_XDECREF(xa);
 Py_XDECREF(ya);
 
 if (face.first) 
 delete [] fillCache;
 delete [] strokeCache;
 return Py::Object();
 
}

 skip> I installed the fink version of mpl on my 10.3.9 laptop the other
 skip> day. I've not been able to work around font problems ...
 John> What version of matplotlib are you using. 
According to fink I am using
 matplotlib-py24 0.84-2
 freetype219 2.1.9-1
 freetype219-shlibs 2.1.9-1
The -1 and -2 are presumably fink package numbers.
 John> I suggest either upgrading to the most recent mpl which should be
 John> tolerant of bad fonts.
Unfortunately, I think I'm as up-to-date as I can get, right?
 John> If that doesn't work, you might want to look into the font_manager
 John> module, and hack the font finding machinery to just return the mpl
 John> system fonts (eg Vera*). If you search for
 John> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
 John> you'll find the spot where the font search list is set and you
 John> could manually hack this. We could provide an override setting
 John> for the font manager in rc that says "just use such and such font
 John> dirs".
Thanks, I'll check into this this evening...
Skip

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> Hey John - Any chance you can put a win32 install file of
 Mark> mpl 0.84 for Python 2.3 on the download page? I am teaching
 Mark> a class on computational methods, and I really would like
 Mark> the students to use the updated axis('equal') functionality.
 Mark> Would be much appreciated.
Hey Mark -- Coincidentally, I've been working on this this morning.
It's been a pain mainly because I have a new build machine and getting
gtk to compile on win32 is no fun. I just uploaded the file so take
it for a test drive and good luck with your class!
JDH

>>>>> "Alexander" == Alexander Borghgraef <ale...@gm...> writes:
 Alexander> One never ceases to learn :-) I discovered ldd, and
 Alexander> when I run it on the offending file _nc_image.so, I see
 Alexander> that libpng isn't linked into it at all. So there's
 Alexander> probably an linking option set wrong in setupext.py
 Alexander> responsable for linking libpng. I'll try and find it,
 Alexander> but if anyone here can save me some time and tell me,
 Alexander> I'd greatly appreciate it.
The place to start poking around is in setupext.py's build_image
This function does a numerix switch to add flags for Numeric and
numarray if it finds them. Both paths (Numeric and numarray) call
 add_agg_flags(module)
and add_agg_flags calls
 module.libraries.append('png')
so libpng should be in your link chain. Since you have a nonstandard
Numeric install, make sure the numerix logic is working as it should
(eg what is the value of "numerix" in build_image?)
I suggest rm -rf ing your build subdir and starting cleanly.
Let us know what you find....
JDH

Hey John -
Any chance you can put a win32 install file of mpl 0.84 for Python 2.3
on the download page?
I am teaching a class on computational methods, and I really would
like the students to use the updated axis('equal') functionality.
Would be much appreciated.
Thanks,
Mark

 Hi,
I'm trying to change a figure I just plot, the size or the face color etc...
I used the figure fonction in ipython:
a = arange(10)
plot(a)
figure(num=1, figsize=(10,10),facecolor='w')
but that change nothing on the figure 1.
I read the doc and I see:
figure : create or change active figure
so there are something I miss or misundertand so could explain me where 
is my error.
Thanks,
Nicolas

Alan G Isaac wrote:
>> On 2005年10月06日, Gary Ruben apparently wrote: 
>>> Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83 
> 
> On Thu, 6 Oct 2005, Alan G Isaac apparently wrote: 
>> You see the \alpha in his example?? 
>> Alan Isaac 
>> Using Win2K + MiKTeX + Matplotlib 0.83.2 
> 
> 
> Oops. Too hair trigger on the send button.
> Deleting the cache worked.
> But why?
I don't know, but I had noticed in the past that this sometimes makes a 
difference. Not that it explains anything, but I'd say that the cache 
mechanism could do with some improvement.
I think it seemed to me to be the font cache rather than the TeX cache 
which made the difference.
I will now relate, for the record, that if anyone is trying to get TeX 
support to work with Windows 98, they will be unsuccessful for the 
following reasons:
There is a problem with MPL's TeX and PS support under Windows 98 where 
Win98 generates resource errors. This is related to Win98's awful pipes 
support; popen2 and popen3 calls basically do not work properly.
I have tried adding close() calls to the pipe input handle following 
each usage of a pipe. The idea is to force the pipes to be flushed. This 
improves the situation, although it does not guarantee a 100% fix, since 
I think the close() call requests that Windows flush and destroy the 
pipes but this can take an indeterminate time to act on. I don't know of 
a better way of doing this like any method of checking that a pipe has 
finished all its I/O activities.
One day I may try changing the os.popen calls to os.spawnl instead, 
since this approach should work.
The other small problem is something I suggested in a previous post 
(dated July 10th) which was not implemented, to do with Win98 returning 
"DVIPNG.EXE" instead of "dvipng" in response to
running "dvipng --version".
The fix here is to change the line:
 if line.startswith('dvipng '):
to
 if line.lower().startswith('dvipng'):
For now, I'll just use my Win2k machine.
Gary

>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:
 Alan> Oops. Too hair trigger on the send button. Deleting the
 Alan> cache worked. But why? I saw the problem the first time I
 Alan> ran his example. What exactly is being cached?
We run a md5 hash on the tex string itself and use that for the base
filename of the cache. The tex , dvi and png files are cached. I am
not sure why you needed to delete the cache on this one. If you can
replicate the problem, perhaps you can take a look at texmanager.py
and see what is going wrong. The module is fairly straigtforward.
Thanks,
JDH

>>>>> "Christopher" == Christopher Mutel <cm...@gm...> writes:
 Christopher> I'm having trouble compiling 0.84 on Python 2.4 /
 Christopher> Ubuntu Hoary (5.04). It seems like when GCC tries to
 Christopher> build ft2font it can't find the two files referenced
 Christopher> in CXX/extensions.hxx and CXX/objects.hxx.
Do you mean CXX/Extensions.hxx and CXX/Objects.hxx? I just untarred
the 0.84 distribution and they are certainly there
 peds-pc311:/var/tmp/matplotlib-0.84> ls CXX/
 Config.hxx cxxsupport.cxx IndirectPythonInterface.cxx Version.hxx
 cxxextensions.c Exception.hxx IndirectPythonInterface.hxx
 cxx_extensions.cxx Extensions.hxx Objects.hxx
Are you running setup.py from the dir in which it resides, eg
 > python setup.py build
If so CXX/Extensions.hxx and CXX/Objects.hxx will be in your '.' (ie
current dir) include path. Perhaps there is a problem with include
flags in setupext.py. Try replacing the add_base_flags function in
that file with this one:
def add_base_flags(module):
 incdirs = [os.path.join(p, 'include') for p in basedir[sys.platform]
 if os.path.exists(p)]
 libdirs = [os.path.join(p, 'lib') for p in basedir[sys.platform]
 if os.path.exists(p)]
 module.include_dirs.extend(incdirs)
 module.include_dirs.append('.') 
 module.library_dirs.extend(libdirs)
 Christopher> I installed (through apt) python-cxx, but this didn't
 Christopher> seem to change anything.
No, we use our own CXX
 Christopher> This seems like a completely trivial problem
 Christopher> (especially compared to the other frutrations I have
 Christopher> had with matplotlib in the past), but I don't know
 Christopher> how to fix it...
Perhaps the approach above will fix it. If not, you may want to
enable universe and multiverse in your /etc/apt/sources.list and then
add
deb http://peds-pc311.bsd.uchicago.edu binary/
and do
 > sudo apt-get update
 > sudo apt-get python-matplotlib-jdh
These are hoary debs that I maintain for our local system. I'm
certainly an amateur debian package maker, but they seem to work and
usually track matplotlib CVS fairly closely.
JDH

>>>>> "skip" == skip <sk...@po...> writes:
 skip> I installed the fink version of mpl on my 10.3.9 laptop the
 skip> other day. I've not been able to work around font problems
 skip> and am looking for suggestions. When I run "ipython -pylab"
 skip> (GTKAgg backend) I get this traceback:
 skip> line 456, in createFontDict font =
 skip> ft2font.FT2Font(str(fpath)) RuntimeError: Could not load
 skip> facefile /Library/Fonts/CharcoalCY.dfont;
 skip> Unknown_File_Format
What version of matplotlib are you using. In recent versions we've
tried to me more friendly about catching exceptions, warning, and then
moving on, rather than failing. There are many mac ttf fonts that
fail and I don't know why (what version of freetype are you using?).
I suggest either upgrading to the most recent mpl which should be
tolerant of bad fonts.
If that doesn't work, you might want to look into the font_manager
module, and hack the font finding machinery to just return the mpl
system fonts (eg Vera*). If you search for
 self.ttffiles = findSystemFonts(paths) + findSystemFonts()
 you'll find the spot where the font search list is set and you could
 manually hack this. We could provide an override setting for the
 font manager in rc that says "just use such and such font dirs".
Let me know if any of this helps,
JDH

> On 2005年10月06日, Gary Ruben apparently wrote:=20
>> Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83=
=20
On Thu, 6 Oct 2005, Alan G Isaac apparently wrote:=20
> You see the \alpha in his example??=20
> Alan Isaac=20
> Using Win2K + MiKTeX + Matplotlib 0.83.2=20
Oops. Too hair trigger on the send button.
Deleting the cache worked.
But why?
I saw the problem the first time I ran his example.
What exactly is being cached?
Thank you,
Alan Isaac

On 2005年10月06日, Gary Ruben apparently wrote:=20
> Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83=
=20
You see the \alpha in his example??
Alan Isaac
Using Win2K + MiKTeX + Matplotlib 0.83.2
Cheers,
Alan Isaac

On 10/6/05, Alexander Borghgraef <ale...@gm...> wrote=
:
>
> We do have several versions of libpng installed, both of libpng10 and
> libpng12. The file /usr/lib/libpng.so is a
> symbolic link to libpng12.so.0.1.2.8, so I suspect that's the version
> which got linked in.
>
One never ceases to learn :-) I discovered ldd, and when I run it on the
offending file _nc_image.so, I see that
libpng isn't linked into it at all. So there's probably an linking option
set wrong in setupext.py responsable for linking
libpng. I'll try and find it, but if anyone here can save me some time and
tell me, I'd greatly appreciate it.
--
Alex Borghgraef

On 10/6/05, Robert Kern <rk...@uc...> wrote:
>
>
> This is a known problem with Numeric. We have resolved this issue in
> scipy_core, Numeric's nascent replacement.
Good news. I'm new to scipy, I've only just installed the previous version,
so I'll skip beta-testing
for this one I think :-) But I'll most likely switch to it when there's a
new release, it's too interesting
not to.
The message you got is a bit misleading.
Aha, so my clumsy workaround did work!
In fact, the problem is that
> _nc_image.so can't find the function png_set_sBIT() which should be in
> libpng. Check which libpng library actually got linked in.
We do have several versions of libpng installed, both of libpng10 and
libpng12. The file /usr/lib/libpng.so is a
symbolic link to libpng12.so.0.1.2.8, so I suspect that's the version which
got linked in.
--
Alex Borghgraef

>>>>> "Ken" == Ken McIvor <mc...@ii...> writes:
 Ken> I would have posted the question to matplotlib-devel had I
 Ken> realized that my answer was going to be presented as a
 Ken> credible opinion on a Debian mailing list. Instead, I just
 Ken> called it as I see it: Debian's release cycle is too slow to
 Ken> accommodate the current pace of matplotlib's development.
 Ken> Please let me know if you are aware of any efforts to get
 Ken> matplotlib into the Debian distribution or if you feel I have
 Ken> misrepresented the situation, and I will happily get the word
 Ken> out.
There have been long-standing efforts to get mpl into ddebian -- I
don't think the version number matters much (ipython is in with
0.something) . Go to google groups and search for matplotlib debian
and sort by date. You'll see fairly recent and ongoing discussions on
getting Vittorio's packages fiished. There were minor nits (eg the
src for the docs should be packaged) but I think it's at the stage of
just getting someone to finally push the go button.
JDH

Hi,
 I cannot get matplotlib to install on my Solaris 10 platform, and would
really appreciate some help.
I've installed the latest version of python from a Solaris 10 package:
% /usr/local/bin/python -V
Python 2.4.2
Added various modules including Numarray and numeric:
% /usr/local/bin/python
Python 2.4.2 (#1, Oct 3 2005, 01:55:05)
[GCC 3.3.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import numarray
>>> import Numeric
>>> ^D
Then downloading and unpacking the latest version, matplotlib-0.84
However, it doesn't matter which version of gcc that I use with
setenv CC gcc
where gcc can be either the version that comes with Solaris 10:
% /usr/sfw/bin/gcc -v
gcc version 3.4.3
% setenv CC /usr/sfw/bin/gcc
% /usr/local/bin/python setup.py build
GTK requires pygtk
GTKAgg requires pygtk
running build
running build_py
creating build
creating build/lib.solaris-2.10-sun4u-2.4
copying lib/pylab.py -> build/lib.solaris-2.10-sun4u-2.4
creating build/lib.solaris-2.10-sun4u-2.4/matplotlib
copying lib/matplotlib/__init__.py ->
build/lib.solaris-2.10-sun4u-2.4/matplotlib
copying lib/matplotlib/_contour.py ->
build/lib.solaris-2.10-sun4u-2.4/matplotlib
...
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
h: In static member function `static wchar_t*
std::char_traits<wchar_t>::move(wchar_t*, cons
t wchar_t*, size_t)':
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
h:336: error: `wmemmove' undeclared (first use this function)
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
h: In static member function `static wchar_t*
std::char_traits<wchar_t>::copy(wchar_t*, cons
t wchar_t*, size_t)':
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
h:340: error: `wmemcpy' undeclared (first use this function)
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
h: In static member function `static wchar_t*
std::char_traits<wchar_t>::assign(wchar_t*, si
ze_t, wchar_t)':
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
h:344: error: `wmemset' undeclared (first use this function)
error: command '/usr/sfw/bin/gcc' failed with exit status 1
(whole message file is the first attachtment)
or my own built version:
/usr/local/bin/gcc -v
gcc version 3.3.2
which matches the version that python itself was built with:
% setenv CC /usr/local/bin/gcc
% /usr/local/bin/python setup.py build
GTK requires pygtk
GTKAgg requires pygtk
running build
running build_py
creating build
creating build/lib.solaris-2.10-sun4u-2.4
copying lib/pylab.py -> build/lib.solaris-2.10-sun4u-2.4
creating build/lib.solaris-2.10-sun4u-2.4/matplotlib
...
/usr/include/pthread.h:305: error: parse error before `)' token
/usr/include/pthread.h:306: error: `pthread_barrierattr_t' was not
declared in
 this scope
/usr/include/pthread.h:306: error: parse error before `,' token
/usr/include/pthread.h:308: error: parse error before `*' token
/usr/include/pthread.h:309: error: `pthread_barrier_t' was not declared in
this
 scope
/usr/include/pthread.h:309: error: parse error before `,' token
/usr/include/pthread.h:311: error: `pthread_barrier_t' was not declared in
this
 scope
/usr/include/pthread.h:311: error: parse error before `)' token
/usr/include/pthread.h:312: error: `pthread_barrier_t' was not declared in
this
 scope
/usr/include/pthread.h:312: error: parse error before `)' token
error: command '/usr/local/bin/gcc' failed with exit status 1
(whole message file is the second attachtment)
Any help would really be appreciated as I need matplotlib to install.
cheers,
hardip
-------------------------------------------------------------------------------
Hardip S. Sanghera (hs...@as...)
Institute of Astronomy Phone (office): 44 (0)1223 766663
Madingley Road Fax: 44 (0)1223 337523
Cambridge CB3 0HA
United Kingdom

Hi Michael,
Your example works fine on my Win2k + MiKTeX setup with Matplotlib 0.83
Perhaps you should try deleting the contents of the .matplotlib cache 
directory. If this doesn't work, what version of Windows & Matplotlib 
are you running and are you using the MiKTeX distribution?
Gary R.
Michael Gilbert wrote:
> Hello all,
> 
> First of all, I would like to say thank you to the matplotlib developers 
> for implementing a nice hack that enables a free python environment to 
> rival the functionality and power of matlab.
> 
> My question is whether it is possible to use the TeX backend to render 
> fonts under the windows versions of matplotlib? I am interested in 
> mixing standard text with math text as labels on plots. The standard 
> matplotlib font backend can almost do this, but it is not robust, is 
> hard to work with, and the results don't look very professional. On the 
> contrary, the TeX backend is clean and conformant (but it only appears 
> to work on UNIX systems with TeX installed). For example, this code
> 
> import pylab
> pylab.rc('text', usetex=True)
> pylab.xlabel(r'normal text ($\alpha$)')
> pylab.plot(range(0,5))
> pylab.show()
> 
> will not work on the windows version of matplotlib, but produces 
> beatiful labels on the linux version. FYI, the above "rc" command is 
> what requests the TeX backend rather than the default.
> 
> Thanks for your thoughts, ideas, and candor.
> 
> Mike Gilbert

Michael Gilbert wrote:
> Hello all,
> 
> First of all, I would like to say thank you to the matplotlib developers
> for implementing a nice hack that enables a free python environment to
> rival the functionality and power of matlab.
> 
> My question is whether it is possible to use the TeX backend to render
> fonts under the windows versions of matplotlib? 
Probably. Do you have TeX installed on your Windows machine?
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

Erik Curiel wrote:
> I'm using subplot() to make two plots stacked on top of each other. The
> problem is, the two plots are stacked *immediately* on top of each
That is quite unusual. Are you sure you're using the subplot commands right?
e.g.
subplot(211)
plot([3,2,5,234])
subplot(212)
plot([3,2,5,234])
> other. How do I add vertical space between them, to separate them?
There are differnt approaches. See that posting:
http://sourceforge.net/mailarchive/message.php?msg_id=12666937
Christian

On Wed, 2005年10月05日 at 13:06 -0600, Samuel M. Smith wrote: 
> On 05 Oct, 2005, at 09:25, Nicholas Young wrote:
> 
> >
> > There's a patch from me on the devel list from sometime ago which
> > contains a patch to add an arrowhead marker style to lines. This
> > obviously isn't a solution but on the off chance its useful its here:
> > http://sourceforge.net/mailarchive/message.php?msg_id=12411835
> >
> 
> So to apply the patch I can manually edit lines.py
> or can I just write my own function. I am not familiar with renderer.
Patches are normally applied using software (which does edit lines.py).
If you are using a *nix system this is patch if not I'm afraid I've no
idea.
All this patch does is automate the process of drawing three lines for
an arrow - as this isn't particularly difficult it might be simpler to
produce your own function if you aren't familiar with patches. The
patch is also against an old CVS version of matplotlib - I can produce a
more up to date one if you do want to use it.
> Also your patch mentions a patch.arrow class. Where is that documented?
The classdoc documentation is here:
http://matplotlib.sourceforge.net/matplotlib.patches.html
To use this you create a patch then add it to the current axis using the
axes.add_patch function.
Nick

Alexander Borghgraef wrote:
> Hi all,
> 
> I just tried installing matplotlib for the first time, and I ran into
> some problems. At first, matplotlib
> didn't compile because it didn't find the locally installed Numeric
> header files, even though those were in
> the python path. I then looked through some documentation, and found I
> had to edit basedir in
> setupext.py, to refer to the local include dirs. Problem here was that
> these header files are under
> $HOME/local/include/python2.3/, and the libs under
> $HOME/local/lib/python2.3/site-packages/, while
> setupext.py seems to expect to find them under basedir/include and
> basedir/lib, so that didn't fix it.
This is a known problem with Numeric. We have resolved this issue in
scipy_core, Numeric's nascent replacement.
> I then simply copy the header files to matplotlib/src/ so the compiler
> would find them anyway, and
> indeed, matplotlib compiled nicely. Alas, it still doesn't work, when I
> try to import pylab in a python shell,
> I get the following error message:
> 
> The import of the numeric version of the _image module,
> _nc_image, failed. This is is either because numeric was
> unavailable when matplotlib was compiled, because a dependency of
> _nc_image could not be satisfied, or because the build flag for
> this module was turned off in setup.py. If it appears that
> _nc_image was not built, make sure you have a working copy of
> numeric and then re-install matplotlib. Otherwise, the following
> traceback gives more details:
> 
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File
> "/homes/morlet/aborghgr/local/lib/python2.3/site-packages/pylab.py",
> line 1, in ?
> from matplotlib.pylab import *
> File
> "/homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/pylab.py",
> line 198, in ?
> from axes import Axes, PolarAxes
> File
> "/homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/axes.py",
> line 24, in ?
> import _image
> File
> "/homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/_image.py",
> line 11, in ?
> from matplotlib._nc_image import *
> ImportError:
> /homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/_nc_image.so:
> undefined symbol: png_set_sBIT
> 
> So Numeric still wasn't found. I suspect this means setup.py didn't
> find the libs when building, but
> why didn't it throw an error? And why wasn't Numeric found? It's
> installed locally, but it's in the path,
> I can import Numeric perfectly in a shell. Anyone care to help?
The message you got is a bit misleading. In fact, the problem is that
_nc_image.so can't find the function png_set_sBIT() which should be in
libpng. Check which libpng library actually got linked in.
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

Hi all,
I just tried installing matplotlib for the first time, and I ran into some
problems. At first, matplotlib
didn't compile because it didn't find the locally installed Numeric header
files, even though those were in
the python path. I then looked through some documentation, and found I had
to edit basedir in
setupext.py, to refer to the local include dirs. Problem here was that thes=
e
header files are under
$HOME/local/include/python2.3/, and the libs under
$HOME/local/lib/python2.3/site-packages/, while
setupext.py seems to expect to find them under basedir/include and
basedir/lib, so that didn't fix it.
I then simply copy the header files to matplotlib/src/ so the compiler woul=
d
find them anyway, and
indeed, matplotlib compiled nicely. Alas, it still doesn't work, when I try
to import pylab in a python shell,
I get the following error message:
The import of the numeric version of the _image module,
_nc_image, failed. This is is either because numeric was
unavailable when matplotlib was compiled, because a dependency of
_nc_image could not be satisfied, or because the build flag for
this module was turned off in setup.py. If it appears that
_nc_image was not built, make sure you have a working copy of
numeric and then re-install matplotlib. Otherwise, the following
traceback gives more details:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/homes/morlet/aborghgr/local/lib/python2.3/site-packages/pylab.py",
line 1, in ?
from matplotlib.pylab import *
File
"/homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/pylab.=
py",
line 198, in ?
from axes import Axes, PolarAxes
File
"/homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/axes.p=
y",
line 24, in ?
import _image
File
"/homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/_image=
.py",
line 11, in ?
from matplotlib._nc_image import *
ImportError:
/homes/morlet/aborghgr/local/lib/python2.3/site-packages/matplotlib/_nc_ima=
ge.so:
undefined symbol: png_set_sBIT
So Numeric still wasn't found. I suspect this means setup.py didn't find th=
e
libs when building, but
why didn't it throw an error? And why wasn't Numeric found? It's installed
locally, but it's in the path,
I can import Numeric perfectly in a shell. Anyone care to help?
--
Alex Borghgraef

On Wed, 5 Oct 2005, Michael Gilbert apparently wrote: 
> import pylab 
> pylab.rc('text', usetex=True) 
> pylab.xlabel(r'normal text ($\alpha$)') 
> pylab.plot(range(0,5)) 
> pylab.show() 
> will not work on the windows version of matplotlib, 
Not really an answer to your question, but:
it looks like a parse error on the parentheses.
Put them inside the math delimiters and it works.
Cheers,
Alan Isaac