matplotlib-devel Mailing List for matplotlib

I've been tooling around with matplotlib, as graciously packaged by 
Chris Barker, and hosted on Bob Ippolito's pythonmac.org/packages site. 
 Everything seems to be working smoothly, but I've run into a couple 
of warnings I can't decrypt.
1) Executing the following code,
#! /usr/bin/pythonw
import pylab
pylab.plot([1, 2, 3], [4, 5, 6])
pylab.show()
displays a chart as expected (the toolbar icons are a little mucked, 
but that's minor). However, dismissing the chart window brings up this 
warning:
2005年03月12日 17:26:52.075 Python[569] *** _NSAutoreleaseNoPool(): Object 
0x66402d0 of class NSCFString autoreleased with no pool in place - just 
leaking
*** malloc[569]: Deallocation of a pointer not malloced: 0x66c73d0; 
This could be a double free(), or free() called with the middle of an 
allocated block; Try setting environment variable MallocHelp to see 
tools to help debug
Is this a bug with matplotlib, with my installation of matplotlib, or 
with my script? Can I ignore it, and if not, what can I do to address 
it?
2) a smaller issue: I tried to change matplotlib's array class by 
opening
/system/library/frameworks/python.framework/version/2.3/share/ 
.matplotlibrc
and changing "numerix : numeric" to "numerix: numarray" but I got the 
following error:
The import of the numarray version of the _contour module,
_na_contour, failed. This is is either because numarray was
unavailable when matplotlib was compiled, because a dependency of
_na_contour could not be satisfied, or because the build flag for
this module was turned off in setup.py. If it appears that
_na_contour was not built, make sure you have a working copy of
numarray and then re-install matplotlib. Otherwise, the following
traceback gives more details:
 File "/platlib/matplotlib/_contour.py", line 5, in ?
ImportError: No module named _na_contour
I know I had numarray installed before unpackaging matplotlib. Chris' 
notes say that he had numeric installed when he packaged matplotlib, 
but makes no mention of numarray. Perhaps the matplotlib.mpkg needs to 
be rebuilt on a machine that has numarray installed? It isn't a big 
deal, as the two types are -mostly- interchangeable, but it would be 
nice to have the choice.
-Brendan
______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

I should have also mentioned that the new signature is document in
backend_bases in the _draw_markers method
 def _draw_markers(self, gc, path, rgbFace, x, y, trans):
 """
 This method is currently underscore hidden because the
 draw_markers method is being used as a sentinel for newstyle
 backend drawing
 path - a matplotlib.agg.path_storage instance
 
 Draw the marker specified in path with graphics context gc at
 each of the locations in arrays x and y. trans is a
 matplotlib.transforms.Transformation instance used to
 transform x and y to display coords. It consists of an
 optional nonlinear component and an affine. You can access
 these two components as
 if transform.need_nonlinear():
 x,y = transform.nonlinear_only_numerix(x, y)
 # the a,b,c,d,tx,ty affine which transforms x and y
 vec6 = transform.as_vec6_val()
 ...backend dependent affine...
 """
 pass

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> John, I noticed ./examples/dash_control.py -dAgg from the
 Steve> latest cvs, is not working..
 Steve> I think the problem may be in lines.set_dashes() If I
 Steve> change self._dashSeq = seq[1] to self._dashSeq = seq it
 Steve> seems to work.
OK, great. Thanks.
 Steve> Also, what happened to matplotlib.path - it was being used
 Steve> by Cairo for draw_markers()
Hmm. I thought I posted this already. I rewrote the path handling to
use agg paths, which are a more complete implementation (eg supporting
move_rel, line_rel and friends. I found my post as an emacs backup
file, so will just paste it in here -- it provides a code snippent to
convert an agg path to a list path we were using previously.
To: Steve Chaplin <ste...@ya...>
Cc: mat...@li...
Subject: Re: [matplotlib-devel] refactoring the backend drawing methods
From: John Hunter <jdh...@ac...>
Gcc: nnml:outgoing-mail
References: <m3u...@pe...>
	<1110376248.3691.24.camel@f1>
X-Draft-From: ("nnml:mail-list.matplotlib-devel" 1256)
--text follows this line--
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I've implemented draw_markers() for Cairo, and tested it
 Steve> using line- styles.py - it seems to be working OK. I did
 Steve> find that it caused draw_lines() to stop working and had to
 Steve> modify it to get it working again.
Yes, sorry for failing to update you on this.
 Steve> I don't think 'fill' and 'fill_rgb' information should be
 Steve> encoded into the 'path', and would to prefer to have
 Steve> rendering separated into two independent steps: 1) call a
 Steve> function to parse 'path' and generate a path - the path is
 Steve> a general path (with no fill or colour info) that you can
 Steve> later use any way you wish. 2) set colour etc as desired
 Steve> and fill/stroke the path.
 Steve> The draw_markers() code I've written calls generate_path()
 Steve> before drawing each marker and it reads the fill value and
 Steve> the fill_rgb each time which it unnecessary since the
 Steve> values are the same for all the markers. Passing the
 Steve> fill_rgb as an extra argument to draw_markers() would be
 Steve> one way to 'fix' this.
Done. I also wrapped agg's path storage and am using this rather than
the list storage. You can get the old representation from the new
rather easily, as illustrated here
import matplotlib.agg as agg
path = agg.path_storage()
path.move_to(10,10)
path.line_to(20,30)
path.curve3_rel(100,200)
path.end_poly()
print [ path.vertex() for i in range(path.total_vertices())] 
 Steve> Cairo (and probably Agg, PS, SVG) supports rel_move_to()
 Steve> and rel_line_to () - so you can define a path using
 Steve> relative rather than absolute coords, which can sometimes
 Steve> be useful. For example, instead of translate(x,y)
 Steve> generate_absolute_path(path) stroke() you can use
 Steve> move_to(x,y) generate_relative_path(path) stroke() and the
 Steve> path is stroked relative to x,y with no need to translate
 Steve> the coordinates.
agg has move_rel and line_rel, etc, but I don't think it works the
same way, because it computes the actual move_to, line_to, etc under
the hood and stores these values, so I'm not sure it's possible to
actually store a relative moveto in agg. Could be missing something,
though. As far as I can see, everything gtes converted to one of the
6 primitive commands (STOP, MOVETO, LINETO, CURVE3, CURVE4, ENDPOLY)
under the hood.
JDH

John,
I noticed
./examples/dash_control.py -dAgg
from the latest cvs, is not working..
I think the problem may be in lines.set_dashes()
If I change
 self._dashSeq = seq[1]
to
 self._dashSeq = seq
it seems to work.
Also, what happened to matplotlib.path - it was being used by Cairo
for draw_markers()
Steve