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