matplotlib-devel Mailing List for matplotlib

Markus,
That is good to know that it has been fixed. As for the difference in
pcolor and pcolormesh, I think it has to do with the fact that pcolormesh is
composed of many lines while pcolor is composed of many polygons. It is
probably more efficient to rasterize polygons than lines.
Ben Root
On Mon, May 31, 2010 at 4:45 AM, Markus Haider <mar...@ui...>wrote:
> > But the displacement issue you see (although think it has been fixed
> > in the svn) needs to be fixed.
>
> Hi,
>
> I just tried out the svn version, and the displacement issue is indeed
> fixed in svn. There is one more question: If I use pcolor with
> rasterized, filesize is 165 kb, if I use pcolormesh it is 864 kb. What
> is the difference between pcolor and pcolormesh?
>
> Greetings,
> Markus
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

By the way, in the current svn version, there is a small white distance
between the image and the axis frame on the right hand and lower side,
if I output to svg.
Greetings,
Markus

> But the displacement issue you see (although think it has been fixed
> in the svn) needs to be fixed.
Hi,
I just tried out the svn version, and the displacement issue is indeed
fixed in svn. There is one more question: If I use pcolor with
rasterized, filesize is 165 kb, if I use pcolormesh it is 864 kb. What
is the difference between pcolor and pcolormesh?
Greetings,
Markus

On Sun, May 30, 2010 at 1:15 PM, John Hunter <jd...@gm...> wrote:
> On Sun, May 30, 2010 at 12:05 PM, Eric Firing <ef...@ha...> wrote:
>> Do you have in mind a dual release--maintenance branch and trunk--or is
>> v0_99_maint abandoned with no release? Another option would be to make
>> a 99 release ASAP and delay the 1.0.
>
> I do want to put out one last maintenance branch release -- I put up
> an rc some time ago and heard no problems so it is good to go. I will
> do it this weekend.
This is done -- the source, win32 binaries and osx binaries have been
uploaded the the sf site, and the site docs are updated to 99.3. I'll
hold off til Tuesday for the official announce.
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3
JDH

Hi,
>> Multiple options (as far as I have understand github). You could use one
>> account with multiple ssh-keys or you can add "contributors" to the repository
>> in the repositorys Admin-panel, which I haven't tried out, yet.
>
> The github TOS allow only one person per account. I guess that's why
> Eric refers to an exception being required.
It's trivial to add people as collaborators to a github repository
(the Admin panel Eric mentioned); that's the equivalent of SVN
per-repository permissions. Adding collaborators gives the
collaborator push access to the repo with their own github user / ssh
key.
http://github.com/guides/managing-collaborators
I guess, by one-person-per-account, github means that only one person
should be logging into the account and administering it, but they did
agree with Fernando a while ago that it was OK to have project
accounts:
http://support.github.com/discussions/email/6289-contact-per-project-account-for-open-source-projects?anon_token=5139fe18a00792fd470a9fe3b7bca187b64ddb8d
See you,
Matthew

On 05/30/2010 05:54 AM, John Hunter wrote:
> now. Everyone who has some free time should tackle outstanding bugs
> on the tracker. I am aware of a compile problem on solaris with CXX6
Appeal to all developers, official or not: there are 95 open bugs listed 
on the tracker at the moment.
I suspect several of these have actually been fixed already--like the 
most recent one, for example--and only need to be closed, ideally with a 
reference to the svn commit that fixed the problem. If you have been 
committing bug fixes, please scan the tracker list, and see if there 
some tickets that you can close as a result of work you have already done.
Beyond that, there are probably quite a few tickets that are out of 
date, or reflect a misunderstanding, or can otherwise be closed fairly 
easily. Please try to identify them and close them.
And last but not least, I'm sure there are real problems identified by 
some of the tickets; and some of them have solutions attached, requiring 
only a review of the proposed solution, possibly some editing and 
testing, and a commit.
Eric

On Sun, May 30, 2010 at 12:05 PM, Eric Firing <ef...@ha...> wrote:
> Do you have in mind a dual release--maintenance branch and trunk--or is
> v0_99_maint abandoned with no release? Another option would be to make
> a 99 release ASAP and delay the 1.0.
I do want to put out one last maintenance branch release -- I put up
an rc some time ago and heard no problems so it is good to go. I will
do it this weekend.
JDH

On 05/30/2010 05:54 AM, John Hunter wrote:
> On Sun, May 30, 2010 at 5:18 AM, Jouni K. Seppänen<jk...@ik...> wrote:
>
>> I agree that there should be a release before the transition.
>
> I was initially reluctant to do a release before the transition
> because of the get_sample_data issue. I was worried that some 1.x
> releases would point to the sf site and some to the github site. I am
> less concerned about that now because we can simply keep the old data
> on the sf site and so releases pointing to it will continue to work
> for the vast majority of examples, and because Jouni has verified that
> the same code works on sf and github modulo a url change.
>
> I will invest some time in the upcoming week getting ready for the
> release. We can target a release candidate for testing a week from
> now. Everyone who has some free time should tackle outstanding bugs
> on the tracker. I am aware of a compile problem on solaris with CXX6
> that we now use, so I will see if I can make some progress on that.
>
John,
Do you have in mind a dual release--maintenance branch and trunk--or is 
v0_99_maint abandoned with no release? Another option would be to make 
a 99 release ASAP and delay the 1.0.
Eric
> JDH
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sun, May 30, 2010 at 5:18 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> I agree that there should be a release before the transition.
I was initially reluctant to do a release before the transition
because of the get_sample_data issue. I was worried that some 1.x
releases would point to the sf site and some to the github site. I am
less concerned about that now because we can simply keep the old data
on the sf site and so releases pointing to it will continue to work
for the vast majority of examples, and because Jouni has verified that
the same code works on sf and github modulo a url change.
I will invest some time in the upcoming week getting ready for the
release. We can target a release candidate for testing a week from
now. Everyone who has some free time should tackle outstanding bugs
on the tracker. I am aware of a compile problem on solaris with CXX6
that we now use, so I will see if I can make some progress on that.
JDH

Malte Dik <mal...@we...> writes:
> Eric Firing wrote:
>
>> 2) If I understand correctly, a key question is who will have commit
>> rights to the master repo on github. It seems that an exception is
>> required to allow that access to more than one person. 
>
> Multiple options (as far as I have understand github). You could use one 
> account with multiple ssh-keys or you can add "contributors" to the repository 
> in the repositorys Admin-panel, which I haven't tried out, yet.
The github TOS allow only one person per account. I guess that's why
Eric refers to an exception being required.
I'm not entirely sure what Github's "public collaborator" feature means
(I can only find documentation about private collaborators, which you
can add if you have a paid account and a private project), but if it
means push access, then I suppose it would help.
>> My sense is that ideally we should have more than one person with
>> that access, but far fewer people than presently have svn commit
>> access. Those with access would then be asked to pull changes into
>> the master from other people's clones--which would be github branches
>> under their control.
Sounds good to me. One possibility is to have an automated tool push
reviewed and tested changes to the "official" repository, similarly to
how the Android Open-Source Project uses Gerrit:
http://source.android.com/source/life-of-a-patch.html
The "verifier" could be just a buildbot-run script that sets the
verified flag if the code passes tests. The "reviewers" could be the
core developers - so instead of pulling other people's changes and
pushing to the official repository, they would just flag the changes as
verified, and the rest would happen automatically.
But maybe that's too much overhead for a project the size of matplotlib.
>> 3) Is it really a good idea to delay the release until the we make
>> the github transition? Given how long it has been since a release,
>> and the possibility that there will be some turbulence until we have
>> had some experience with github, I think it would be better to
>> release first and transition immediately afterwards.
I agree that there should be a release before the transition. 
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
> 
> 2) If I understand correctly, a key question is who will have commit
> rights to the master repo on github. It seems that an exception is
> required to allow that access to more than one person. My sense is that
> ideally we should have more than one person with that access, but far
> fewer people than presently have svn commit access. Those with access
> would then be asked to pull changes into the master from other people's
> clones--which would be github branches under their control.
Multiple options (as far as I have understand github). You could use one 
account with multiple ssh-keys or you can add "contributors" to the repository 
in the repositorys Admin-panel, which I haven't tried out, yet.
Regards,
Malte

On 2010年5月29日 12:28:40 -1000, Eric Firing <ef...@ha...> wrote:
> 3) Is it really a good idea to delay the release until the we make the
> github transition? Given how long it has been since a release, and the
> possibility that there will be some turbulence until we have had some
> experience with github, I think it would be better to release first and
> transition immediately afterwards.
I've had unanticipated time commitments come up that have limited the time I have available for work on MPL. I had been planning spending some time to facilitate a switch to git but now can't see where the time will come from (in the next several weeks at least). Therefore I think making a release before any VCS switch is a good idea.
-Andrew

On 05/28/2010 10:00 AM, Ryan May wrote:
> Hi,
>
> Ben Root gave me a bug report that pcolormesh (and hence QuadMesh)
> were not respecting zorder. This turns out to be due to the fact that
> kwargs are not being forwarded on as appropriate. This is easy enough
> to fix and make work, but I wanted to first ask for any insight on the
> following "helpful" comment in axes.py:
>
> collection = mcoll.QuadMesh(
> Nx - 1, Ny - 1, coords, showedges,
> antialiased=antialiased, shading=shading) # kwargs are not used
>
> (It's be great if this comment gave some actual reasoning rather than
> stating the obvious).
>
> Anyone know if there's an explicit design choice for QuadMesh not
> taking kwargs, or is it just an omission?
>
> Ryan
>
Ryan,
I don't know based on any recollection of how the code got that way, but 
it certainly looks like a historical artifact, and not something that 
needs to be preserved. I think you should go ahead and change it. If 
no tests or examples break, then it looks safe enough.
Eric

On 04/23/2010 02:44 AM, John Hunter wrote:
> On Thu, Apr 22, 2010 at 4:40 PM, Sandro Tosi<mo...@de...> wrote:
>> Hello all,
>> in some time (let's say a couple of months, maybe more) Debian will
>> enter the "freeze" period, where no new upstream releases are
>> accepted, in order to prepare the best stable release we can :)
>>
>> In the past months I see many changes are accumulated in the SVN but
>> no new release are done. I don't know if you've already discussed
>> about releasing mpl, but it would be nice if we can have something
>> before the freeze, so to have a quite-update mpl in squeeze.
>>
>> > From my POV, I'll provide all the support needed, so if there
>> something I can do just tell me :)
>
> Hey Sandro,
>
> thanks for the head's up. We would like to get a 1.0 release out and
> there are two roadbumps we have to navigate first. We'd like to
> transition our VCS to git, and this impacts our release schedule
John et al.,
1) It looks like numpy is about to make the jump to github. Their 
discussion includes interesting points of strategy. Their intention is 
to develop the strategy via an NEP.
2) If I understand correctly, a key question is who will have commit 
rights to the master repo on github. It seems that an exception is 
required to allow that access to more than one person. My sense is that 
ideally we should have more than one person with that access, but far 
fewer people than presently have svn commit access. Those with access 
would then be asked to pull changes into the master from other people's 
clones--which would be github branches under their control.
3) Is it really a good idea to delay the release until the we make the 
github transition? Given how long it has been since a release, and the 
possibility that there will be some turbulence until we have had some 
experience with github, I think it would be better to release first and 
transition immediately afterwards.
Eric
> because of the "get_sample_data" support in the trunk which currently
> pulls the data from svn but would have to be refactored to pull from
> hit and we'd like to make the transition before we do a release.
> Andrew, who is handling the git transition, has been very tied up of
> late, but thinks he'll have some time in early May. The other issue
> is my dead OSX build box -- I have access to a 64bit python 2.6
> platform for builds for OSX, but currently no other platforms/versions
> so I have to sink some time into this for a release, though this is
> not a show stopper as we could do a release with incomplete binary
> support for OSX.
>
> So keep our feet to the fire and make sure we don't fall too far
> behind so we can get something out before the freeze, hopefully far
> enough before the freeze that we can get at least one bugfix release
> out...
>
> JDH
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter <jd...@gm...> writes:
>> Has it been decided where the master repository would be hosted? The
>> current code seems to handle at least github just fine if you just
>> replace the base URL in cbook.py:
>
> We've been planning on using github. I'm surprised the existing code
> works -- have you tested to see whether the cacheing w/ revision
> number works under github, ie it only pulls down new data when the
> revision number changes?
Yes. The code is essentially a simple HTTP client, and it works right on
account of the logic at the server. The server sets an ETag header when
it sends a file, and on further requests replies with 304 Not Modified
if the client knows the current ETag value, or with 200 OK if the value
is stale.
For example, running the date_index_formatter.py example with
verbose=debug and an empty cache directory:
ViewVCCachedServer: files listed in cache.pck: set([])
ViewVCCachedServer: files in cache directory: set([])
ViewVCCachedServer: retrieving http://github.com/jkseppan/mpl-sample-data/raw/master/aapl.csv
ViewVCCachedServer: received response 200: OK
loading /Users/jks/.matplotlib/sample_data/aapl.csv
Next run:
ViewVCCachedServer: files listed in cache.pck: set(['/Users/jks/.matplotlib/sample_data/aapl.csv'])
ViewVCCachedServer: files in cache directory: set(['/Users/jks/.matplotlib/sample_data/cache.pck', '/Users/jks/.matplotlib/sample_data/aapl.csv'])
ViewVCCachedServer: retrieving http://github.com/jkseppan/mpl-sample-data/raw/master/aapl.csv
ViewVCCachedServer: received response 304: Not Modified
ViewVCCachedServer: reading data file from cache file "/Users/jks/.matplotlib/sample_data/aapl.csv"
loading /Users/jks/.matplotlib/sample_data/aapl.csv
Then, after committing a new version in the repository:
ViewVCCachedServer: files listed in cache.pck: set(['/Users/jks/.matplotlib/sample_data/aapl.csv'])
ViewVCCachedServer: files in cache directory: set(['/Users/jks/.matplotlib/sample_data/cache.pck', '/Users/jks/.matplotlib/sample_data/aapl.csv'])
ViewVCCachedServer: retrieving http://github.com/jkseppan/mpl-sample-data/raw/master/aapl.csv
ViewVCCachedServer: received response 200: OK
loading /Users/jks/.matplotlib/sample_data/aapl.csv
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

A while ago, John Hunter wrote:
> We'd like to transition our VCS to git, and this impacts our release
> schedule because of the "get_sample_data" support in the trunk which
> currently pulls the data from svn but would have to be refactored to
> pull from [git] and we'd like to make the transition before we do a
> release.
Has it been decided where the master repository would be hosted? The
current code seems to handle at least github just fine if you just
replace the base URL in cbook.py:
- baseurl = 'http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/'
+ baseurl = 'http://github.com/jkseppan/mpl-sample-data/raw/master/'
(I just created that repository for testing purposes, and made a small
change to a file when testing, so it shouldn't become the final
repository.)
The code is really not specific to any version control system, but just
assumes that the files can be retrieved from an HTTP server that has
some basic conditional-get support.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks, John!
Calling ax.autoscale_view after ax.relim makes the script work.
Best regards,
Pearu

Hi,
Ben Root gave me a bug report that pcolormesh (and hence QuadMesh)
were not respecting zorder. This turns out to be due to the fact that
kwargs are not being forwarded on as appropriate. This is easy enough
to fix and make work, but I wanted to first ask for any insight on the
following "helpful" comment in axes.py:
 collection = mcoll.QuadMesh(
 Nx - 1, Ny - 1, coords, showedges,
 antialiased=antialiased, shading=shading) # kwargs are not used
(It's be great if this comment gave some actual reasoning rather than
stating the obvious).
Anyone know if there's an explicit design choice for QuadMesh not
taking kwargs, or is it just an omission?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Thanks, John!
Adding ax.autoscale_view after ax.relim makes the script work correctly.
Best regards,
Pearu

On Fri, May 28, 2010 at 1:37 PM, Pearu Peterson <pe...@ce...> wrote:
> While the new data is plotted correctly, the plot shows fixed axes
> from the first plot call. What I am doing wrong?
ax.relim() causes the data limits to be updated based on the current
objects it contains, ax.autoscale_view() causes the view limits to be
updated based on the data limits, and fig.canvas.draw() forces a
redraw.
JDH

On Fri, May 28, 2010 9:15 pm, John Hunter wrote:
> On Fri, May 28, 2010 at 1:04 PM, Pearu Peterson <pe...@ce...> wrote:
>
>> Regarding reusing existing line --- I have understood that this
>> will work only if the length of the line data does not change.
>
> This is not correct -- you can change the line length with calls to
> set_data
>
>> In my case the data grows as more data points are acquired and I have
>> not figured out how to make axes to set new limits after changing
>> the line data.
>
> ax.relim()
Ok, very good. However, it does not seem to have effect. Consider
the following example:
#
import numpy
from numpy.testing.utils import memusage
import matplotlib
matplotlib.use('GTKAgg')
import matplotlib.pyplot as plt
fig = plt.figure()
axes1 = fig.add_subplot( 111 )
def animate():
 x = [0]
 while 1:
 y = numpy.random.rand (len (x))
 if 1:
 # updating line in place
 if not axes1.lines:
 line, = axes1.plot(x, y, 'b')
 else:
 line.set_data(x, y)
 # relim does not have effect in updating axes
 axes1.relim()
 else:
 # demonstrates expected behaviour, has leakage w/o Mike patch
 for line in axes1.lines:
 line.remove()
 line, = axes1.plot(x, y, 'b')
 fig.canvas.draw()
 print memusage ()/(1024.0*1024.0),"MB", len (axes1.lines), len(x)
 x.append(x[-1]+1)
import gobject
print 'adding idle'
gobject.idle_add(animate)
print 'showing'
plt.show()
#eof
While the new data is plotted correctly, the plot shows fixed axes
from the first plot call. What I am doing wrong?
Pearu

On 05/28/2010 08:04 AM, Pearu Peterson wrote:
> On Fri, May 28, 2010 5:12 pm, John Hunter wrote:
>
>> Hey Pearu -- thanks for the report. We'll try and track down and fix
>> this leak. In the interim, would an acceptable work around for you be
>> to *reuse* an existing line by calling set_data on it. That way you
>> wouldn't have to do the add/remove that is causing your leak. Have
>> you confirmed this leak on various backends (eg Agg, PDF, PS)?
>
> No, I haven't but I can try it.
>
> Regarding reusing existing line --- I have understood that this
> will work only if the length of the line data does not change.
Not so.
> In my case the data grows as more data points are acquired and I have
> not figured out how to make axes to set new limits after changing
> the line data.
lineobj = plot([0], [0])[0]
ax = gca()
x = np.arange(10)
y = 20 * np.sin(x)
lineobj.set_data(x, y)
xy = np.concatenate((x[:,np.newaxis], y[:,np.newaxis]), axis=1)
ax.update_datalim(xy)
ax.autoscale_view()
draw()
Eric
>
> Currently I am using a work around where the axes are cleared
> after every 60 seconds - this seems to keep memory usage under control.
>
> It seems that Mike has resolved the problem. I'll try the latest
> SVN..
>
> Thanks!
> Pearu
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, May 28, 2010 at 1:04 PM, Pearu Peterson <pe...@ce...> wrote:
> Regarding reusing existing line --- I have understood that this
> will work only if the length of the line data does not change.
This is not correct -- you can change the line length with calls to set_data
> In my case the data grows as more data points are acquired and I have
> not figured out how to make axes to set new limits after changing
> the line data.
ax.relim()
Cheers,
JDH

On Fri, May 28, 2010 5:12 pm, John Hunter wrote:
> Hey Pearu -- thanks for the report. We'll try and track down and fix
> this leak. In the interim, would an acceptable work around for you be
> to *reuse* an existing line by calling set_data on it. That way you
> wouldn't have to do the add/remove that is causing your leak. Have
> you confirmed this leak on various backends (eg Agg, PDF, PS)?
No, I haven't but I can try it.
Regarding reusing existing line --- I have understood that this
will work only if the length of the line data does not change.
In my case the data grows as more data points are acquired and I have
not figured out how to make axes to set new limits after changing
the line data.
Currently I am using a work around where the axes are cleared
after every 60 seconds - this seems to keep memory usage under control.
It seems that Mike has resolved the problem. I'll try the latest
SVN..
Thanks!
Pearu

There is a fix in r8341. It passes the regression tests, and all of the 
event handling examples I tried seem to still work.
It seems that many places in matplotlib were never disconnecting 
callbacks, and these callbacks keep references to the destination 
objects alive.
Unfortunately, it's not quite obvious where the "disconnect" calls 
should be added -- the lifetime of objects isn't very symmetrical. For 
example, the "units" callback is set up by Lines2D inside of its 
"set_axes" method, but there is no "remove_axes" method in which to put 
the disconnect. Tracking down all of the ways in which a line could be 
removed from an axes seems daunting.
Instead, my solution is to store weak references to the methods stored 
in the CallbackRegistry -- that way the CallbackRegistry won't leak 
references like it does now. Since the Python stdlib weakref module 
doesn't directly support weak references to bound methods, the whole 
thing is a bit hairy -- but I think it's a more permanent solution than 
trying to ensure that all callbacks get explicitly disconnected.
As this change is rather fundamental and may have unintended 
consequences, please play with it in your contexts and let me know if 
you see anything strange.
Mike
On 05/28/2010 10:47 AM, Michael Droettboom wrote:
> I'm on to something -- some callbacks are being created that are never
> disconnected.
>
> In Line2D.set_axes:
>
> self._xcid = ax.xaxis.callbacks.connect('units', self.recache_always)
>
> gets called twice. This is problematic because the id of the first
> connection is simply lost. Also, there doesn't seem to be any code to
> attempt to remove either of them.
>
> I'm looking into it further -- forcibly deleting these callbacks reduces
> the reference count on the line object, but doesn't seem to completely
> eliminate the leak.
>
> Mike
>
> On 05/28/2010 10:12 AM, John Hunter wrote:
> 
>> On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson<pe...@ce...> wrote:
>>
>> 
>>> Hi,
>>>
>>> In an application that updates a plot with
>>> new experimental data, say, every second and the experiment
>>> can last hours, I have tried two approaches:
>>> 1) clear axes and plot new experimental data - this is
>>> slow and takes too much cpu resources.
>>> 2) remove lines and plot new experimental data - this is
>>> fast enough but unfortunately there seems to be a memory
>>> leakage, the application runs out of memory.
>>>
>>> Here follows a simple script that demonstrates the
>>> leakage problem:
>>>
>>> #
>>> import numpy
>>> from numpy.testing.utils import memusage
>>> import matplotlib.pyplot as plt
>>> x = range (1000)
>>> axes1 = plt.figure().add_subplot( 111 )
>>> y = numpy.random.rand (len (x))
>>> while 1:
>>> if 1:
>>> # leakage
>>> for line in axes1.lines:
>>> if line.get_label ()=='data':
>>> line.remove()
>>> else:
>>> # no leak, but slow
>>> axes1.clear()
>>> axes1.plot(x, y, 'b', label='data')
>>> print memusage (), len (axes1.lines)
>>> #eof
>>>
>>> When running the script, the memory usage
>>> is increasing by 132 kbytes per iteration, that is,
>>> with an hour this example application will consume
>>> 464MB RAM while no new data has been generated. In real
>>> application this effect will be even worse.
>>>
>>> So, I am looking for an advice how to avoid
>>> this memory leakage without clearing axes.
>>>
>>> 
>> Hey Pearu -- thanks for the report. We'll try and track down and fix
>> this leak. In the interim, would an acceptable work around for you be
>> to *reuse* an existing line by calling set_data on it. That way you
>> wouldn't have to do the add/remove that is causing your leak. Have
>> you confirmed this leak on various backends (eg Agg, PDF, PS)?
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA