matplotlib-users Mailing List for matplotlib

On 11/18/10 5:05 PM, John Hunter wrote:
> On Thu, Nov 18, 2010 at 2:20 PM, Benjamin Root<ben...@ou...> wrote:
>
>> Interesting analysis. One possible source of a leak would be some sort of
>> dangling reference that still hangs around even though the plot objects have
>> been cleared. By the time of the matplotlib 1.0.0 release, we did seem to
>> clear out pretty much all of these, but it is possible there are still some
>> lurking about. We should probably run your script against the latest svn to
>> see how the results compare.
>
> In our experience, many of the GUI backends have some leak, and these
> are in the GUI and not in mpl. Caleb, can you see if you can
> replicate the leak with your example code using the agg backend (no
> GUI). If so, could you post the code that exposes the leak. if not,
> I'm afraid it is in wx and you might need to deal with the wx
> developers.
Heh. Good timing! I just fixed a bug in Chaco involving a leaking cycle that the 
garbage collector could not clean up. The lesson of my tale of woe is that even 
if there is no leak when you run without wxPython, that doesn't mean that 
wxPython is the culprit.
If any object in the connected graph containing a cycle (even if it does not 
directly participate in the cycle) has an __del__ method in pure Python, then 
the garbage collector will not clean up that cycle for safety reasons. Read the 
docs for the gc module for details. We use SWIG to wrap Agg and SWIG adds 
__del__ methods for all of its classes. wxPython uses SWIG and has the same 
problems. If there is a cycle which can reach a wxPython object, the cycle will 
leak. The actual cycle may be created by matplotlib, though.
You can determine if this is the case pretty easily, though. Call gc.collect() 
then examine the list gc.garbage. This will contain all of those objects with a 
__del__ that prevented a cycle from being collected.
I recommend using objgraph to diagram the graph of references to those objects. 
It's invaluable to actually see what's going on.
 http://pypi.python.org/pypi/objgraph
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Thu, Nov 18, 2010 at 2:20 PM, Benjamin Root <ben...@ou...> wrote:
> Interesting analysis. One possible source of a leak would be some sort of
> dangling reference that still hangs around even though the plot objects have
> been cleared. By the time of the matplotlib 1.0.0 release, we did seem to
> clear out pretty much all of these, but it is possible there are still some
> lurking about. We should probably run your script against the latest svn to
> see how the results compare.
In our experience, many of the GUI backends have some leak, and these
are in the GUI and not in mpl. Caleb, can you see if you can
replicate the leak with your example code using the agg backend (no
GUI). If so, could you post the code that exposes the leak. if not,
I'm afraid it is in wx and you might need to deal with the wx
developers.
JDH

On Thu, Nov 18, 2010 at 1:11 PM, Caleb Constantine <cad...@gm...>wrote:
> Matplotlib Users:
>
> It seems matplotlib plotting has a relatively small memory leak. My
> experiments suggest it leaks between 5K and 8K bytes of RAM for ever plot
> redraw. For example, in one experiment, plotting the same buffer (so as to
> not
> allocate new memory) every second for a period of about 12 hours resulted
> in
> memory usage (physical RAM) increasing by approximately 223MB, which is
> about
> 5.3K per replot. The plotting code is:
>
> class PlotPanel(wx.Panel):
> def __init__(self, parent):
> wx.Panel.__init__(self, parent, wx.ID_ANY,
> style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
> self._figure = MplFigure(dpi=None)
> self._canvas = MplCanvas(self, -1, self._figure)
> self._axes = self._figure.add_subplot(1,1,1)
>
> sizer = wx.BoxSizer(wx.VERTICAL)
> sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
> self.SetSizer(sizer)
>
> def draw(self, channel, seconds):
> self._axes.clear()
> self._axes.plot(channel, seconds)
> self._canvas.draw()
>
>
> `draw()` is called every second with the same `channels` and `seconds`
> numpy.array buffers.
>
> In my case, this leak, though relatively small, becomes a serious issue
> since
> my software often runs for long periods of time (days) plotting data
> streamed
> from a data acquisition unit.
>
> Any suggestions will help. Am I miss understanding something here? Maybe I
> need to call some obscure function to free memory, or something?
>
> My testing environment:
>
> * Windws XP SP3, Intel Core 2 Duo @ 2.33GHz, 1.96 GB RAM
> * Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit
> (Intel)] on win32
> * matplotlib version 1.0.0
> * numpy 1.4.1
> * wxPython version 2.8.11.0
>
> The complete test program follows.
>
> Thanks,
>
> Caleb
>
>
> from random import random
> from datetime import datetime
> import os
> import time
> import win32api
> import win32con
> import win32process
>
> import wx
> import numpy
>
> import matplotlib as mpl
> from matplotlib.figure import Figure as MplFigure
> from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as
> MplCanvas
>
> def get_process_memory_info(process_id):
> memory = {}
> process = None
> try:
> process = win32api.OpenProcess(
> win32con.PROCESS_QUERY_INFORMATION|win32con.PROCESS_VM_READ,
> False, process_id);
> if process is not None:
> return win32process.GetProcessMemoryInfo(process)
> finally:
> if process:
> win32api.CloseHandle(process)
> return memory
>
> meg = 1024.0 * 1024.0
>
> class PlotPanel(wx.Panel):
> def __init__(self, parent):
> wx.Panel.__init__(self, parent, wx.ID_ANY,
> style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
> self._figure = MplFigure(dpi=None)
> self._canvas = MplCanvas(self, -1, self._figure)
> self._axes = self._figure.add_subplot(1,1,1)
>
> sizer = wx.BoxSizer(wx.VERTICAL)
> sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
> self.SetSizer(sizer)
>
> def draw(self, channel, seconds):
> self._axes.clear()
> self._axes.plot(channel, seconds)
> self._canvas.draw()
>
> class TestFrame(wx.Frame):
> def __init__(self, parent, id, title):
> wx.Frame.__init__(
> self, parent, id, title, wx.DefaultPosition, (600, 400))
>
> self.testDuration = 60 * 60 * 24
> self.startTime = 0
>
> self.channel = numpy.sin(numpy.arange(1000) * random())
> self.seconds = numpy.arange(len(self.channel))
>
> self.plotPanel = PlotPanel(self)
>
> sizer = wx.BoxSizer(wx.VERTICAL)
> sizer.Add(self.plotPanel, 1 ,wx.EXPAND)
> self.SetSizer(sizer)
>
> self._timer = wx.Timer(self)
> self.Bind(wx.EVT_TIMER, self._onTimer, self._timer)
> self._timer.Start(1000)
> print "starting memory: ",\
> get_process_memory_info(os.getpid())["WorkingSetSize"]/meg
>
> def _onTimer(self, evt):
> if self.startTime == 0:
> self.startTime = time.time()
>
> if (time.time() - self.startTime) >= self.testDuration:
> self._timer.Stop()
>
> self.plotPanel.draw(self.channel, self.seconds)
>
> t = datetime.now()
> memory = get_process_memory_info(os.getpid())
> print "time: {0}, working: {1:f}".format(
> t, memory["WorkingSetSize"]/meg)
>
> class MyApp(wx.App):
> def OnInit(self):
> frame = TestFrame(None, wx.ID_ANY, "Memory Leak")
> self.SetTopWindow(frame)
> frame.Show(True)
> return True
>
> if __name__ == '__main__':
> app = MyApp(0)
> app.MainLoop()
>
>
>
Caleb,
Interesting analysis. One possible source of a leak would be some sort of
dangling reference that still hangs around even though the plot objects have
been cleared. By the time of the matplotlib 1.0.0 release, we did seem to
clear out pretty much all of these, but it is possible there are still some
lurking about. We should probably run your script against the latest svn to
see how the results compare.
Another possibility might be related to numpy. However this is the draw
statement, so I don't know how much numpy is used in there. The latest
refactor work in numpy has revealed some memory leaks that have existed, so
who knows?
Might be interesting to try making equivalent versions of this script using
different backends, and different package versions to possibly isolate the
source of the memory leak.
Thanks for your observations,
Ben Root

Matplotlib Users:
It seems matplotlib plotting has a relatively small memory leak. My
experiments suggest it leaks between 5K and 8K bytes of RAM for ever plot
redraw. For example, in one experiment, plotting the same buffer (so as to
not
allocate new memory) every second for a period of about 12 hours resulted in
memory usage (physical RAM) increasing by approximately 223MB, which is
about
5.3K per replot. The plotting code is:
 class PlotPanel(wx.Panel):
 def __init__(self, parent):
 wx.Panel.__init__(self, parent, wx.ID_ANY,
 style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
 self._figure = MplFigure(dpi=None)
 self._canvas = MplCanvas(self, -1, self._figure)
 self._axes = self._figure.add_subplot(1,1,1)
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
 self.SetSizer(sizer)
 def draw(self, channel, seconds):
 self._axes.clear()
 self._axes.plot(channel, seconds)
 self._canvas.draw()
`draw()` is called every second with the same `channels` and `seconds`
numpy.array buffers.
In my case, this leak, though relatively small, becomes a serious issue
since
my software often runs for long periods of time (days) plotting data
streamed
from a data acquisition unit.
Any suggestions will help. Am I miss understanding something here? Maybe I
need to call some obscure function to free memory, or something?
My testing environment:
 * Windws XP SP3, Intel Core 2 Duo @ 2.33GHz, 1.96 GB RAM
 * Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit
 (Intel)] on win32
 * matplotlib version 1.0.0
 * numpy 1.4.1
 * wxPython version 2.8.11.0
The complete test program follows.
Thanks,
Caleb
from random import random
from datetime import datetime
import os
import time
import win32api
import win32con
import win32process
import wx
import numpy
import matplotlib as mpl
from matplotlib.figure import Figure as MplFigure
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as MplCanvas
def get_process_memory_info(process_id):
 memory = {}
 process = None
 try:
 process = win32api.OpenProcess(
 win32con.PROCESS_QUERY_INFORMATION|win32con.PROCESS_VM_READ,
 False, process_id);
 if process is not None:
 return win32process.GetProcessMemoryInfo(process)
 finally:
 if process:
 win32api.CloseHandle(process)
 return memory
meg = 1024.0 * 1024.0
class PlotPanel(wx.Panel):
 def __init__(self, parent):
 wx.Panel.__init__(self, parent, wx.ID_ANY,
 style=wx.BORDER_THEME|wx.TAB_TRAVERSAL)
 self._figure = MplFigure(dpi=None)
 self._canvas = MplCanvas(self, -1, self._figure)
 self._axes = self._figure.add_subplot(1,1,1)
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(self._canvas, 1, wx.EXPAND|wx.TOP, 5)
 self.SetSizer(sizer)
 def draw(self, channel, seconds):
 self._axes.clear()
 self._axes.plot(channel, seconds)
 self._canvas.draw()
class TestFrame(wx.Frame):
 def __init__(self, parent, id, title):
 wx.Frame.__init__(
 self, parent, id, title, wx.DefaultPosition, (600, 400))
 self.testDuration = 60 * 60 * 24
 self.startTime = 0
 self.channel = numpy.sin(numpy.arange(1000) * random())
 self.seconds = numpy.arange(len(self.channel))
 self.plotPanel = PlotPanel(self)
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(self.plotPanel, 1 ,wx.EXPAND)
 self.SetSizer(sizer)
 self._timer = wx.Timer(self)
 self.Bind(wx.EVT_TIMER, self._onTimer, self._timer)
 self._timer.Start(1000)
 print "starting memory: ",\
 get_process_memory_info(os.getpid())["WorkingSetSize"]/meg
 def _onTimer(self, evt):
 if self.startTime == 0:
 self.startTime = time.time()
 if (time.time() - self.startTime) >= self.testDuration:
 self._timer.Stop()
 self.plotPanel.draw(self.channel, self.seconds)
 t = datetime.now()
 memory = get_process_memory_info(os.getpid())
 print "time: {0}, working: {1:f}".format(
 t, memory["WorkingSetSize"]/meg)
class MyApp(wx.App):
 def OnInit(self):
 frame = TestFrame(None, wx.ID_ANY, "Memory Leak")
 self.SetTopWindow(frame)
 frame.Show(True)
 return True
if __name__ == '__main__':
 app = MyApp(0)
 app.MainLoop()

Goals: date plot with two y axes (plotting completely different things)
 point picking and point labeling
 As many lines as user wants, all colored differently.
Having some problems with this. (matplotlib 0.98.5)
1) There is a known bug with twinx() and plot_date:
http://sourceforge.net/tracker/index.php?func=detail&aid=3046812&group_id=80706&atid=560720
But I can get it to work if I change ONE OF the plot_date() calls (the
one for the values plotted to the right-hand y axis) to just plot().
Is that going to introduce problems? Is there a better workaround?
(The ones on that page don't work for me).
2) How can I get the lines belonging to different axes to cycle
through colors such that the same color is not used for any lines
shown in the plot? (that is, I don't want to hard code a color to any
line, I want it to auto-cycle).
3) My point picking is not working with the two axes. In my routine,
I label the picked point and to do that I have to make reference to
its axis and call plot_date(). How can I know which axis the picked
point came from, so that I can label it appropriately?
Sorry this is a little stirred together, but hoping I can get some
hints to allow me to work it into shape.
Thanks,
Che

Folks, I was trying to use an object oriented approach to creating
colorbars, but I could manage to make it work. Currently I have close
to what I am trying to achieve, but the last bits are missing. The
outstanding issues are:
1) I only need one colorbar, how would I create a single colorbar on
the right that spanned across all axes? (ie. same height as the stack)
2) is there a way to place the colorbar in the bottom middle of my
panels (if I end up with more than one)?
3) How can I customize the tick labels of the colorbar?
4) Is this a 'pythonic' approach to begin with?
Here's my code, and a fake class that should provide the data needed
to use the example:
#!/usr/bin/env python
"""
Demo to help understand plotting tools
"""
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt
class Fun(object):
 """ Dummy class for testing
 """
 class body:
 pass
 def __init__(self):
 body = Fun.body
 body.time = np.arange(1000)
 body.alt = np.sin(body.time)
 body.A = 360*np.random.random_sample(1000)-180
 body.B = 180*np.random.random_sample(1000)-90
 body.C = 90*np.random.random_sample(1000)-45
def plot_angles(F):
 """ Plots the angles of body """
 from mpl_toolkits.axes_grid1.inset_locator import inset_axes
 # Set up plotting environment colors
 Nc = np.arange(-180,181,1)
 norm = mpl.colors.normalize(Nc.min(),Nc.max())
 fig, (ax1, ax2, ax3) = plt.subplots(3, sharex=True, sharey=True)
 ax1.scatter(F.body.time,F.body.alt,c=F.body.A,norm=norm,label='A',edgecolor='none')
 ax2.scatter(F.body.time,F.body.alt,c=F.body.B,norm=norm,label='B',edgecolor='none')
 ax3.scatter(F.body.time,F.body.alt,c=F.body.C,norm=norm,label='C',edgecolor='none')
 # Fine-tune figure; make subplots close to each other and hide x ticks for
 # all but bottom plot.
 fig.subplots_adjust(hspace=0)
 plt.setp([a.get_xticklabels() for a in fig.axes[:-1]], visible=False)
 for a in fig.axes:
 ia = inset_axes(a,width="20%", height="5%", loc=4)
 a.set_xlim(F.body.time[0],F.body.time[-1])
 fig.add_subplot(a)
 plt.colorbar(a.collections[0],cax=ia,orientation='horizontal')
 ia.xaxis.set_ticks_position("top")
 plt.draw()
 return fig
def demo():
 F = Fun()
 plot_angles(F)
if __name__ == "__main__":
 fig = demo()
 plt.show()

Ok problem(s) solved, thanks a lot for the efficient help (this also taught me 
how to go through the code more thoroughly)
* for the record: I had a pylab.py in the site-packages directory, probably a 
left-over from some other installation, which was interfering with the pylab.py 
which should be the one under matplotlib/. I just removed it now and it works well.
* and you were right, the funny "try this" was a left over of many tests I had 
done to track down the problem (mea culpa on that one)
thanks again, all works beautifully (and consistently) now.
cheers
Eric

Am 17/11/10, schrieb Benjamin Root <ben...@ou...>:
> On Wed, Nov 17, 2010 at 8:44 AM, Benjamin Root <ben...@ou... <ben...@ou...>> wrote:
> 
> > 
> > 
> > 
> > 
> > 
> > 
> > On Wed, Nov 17, 2010 at 5:45 AM, Matthias Plum <pl...@ph...(javascript:main.compose()> wrote:
> > 
> > 
> > 
> > > 
> > > Hi
> > > 
> > > 
> > > 
> > > I am trying to plot data on the sphere and use the hammer projection.
> > > 
> > > The data ploting works fine, but the angular grid isn't shown correctly.
> > > 
> > > In the attached picture you can see the error(mouse pointer is on the
> > > 
> > > position 60 E 30 S). Can anyone help me on this subject? Thanks.
> > > 
> > > 
> > > 
> > > Matthias
> > > 
> > > 
> > > 
> > 
> > 
> > Matthias,
> > 
> > Looking at the transform equation for Hammer, it looks like there might be a mistake in the calculation. Can you include the script you used to make that figure so I can test the fix?
> > 
> > 
> > 
> > 
> > Thanks,
> > Ben Root
> > 
> > 
> > 
> 
> Nevermind about the example script, I tested it myself and verified the problem. The fix was simple. We were missing a square root for the denominator of the formula for x and y. Before I submit this patch, can anybody with more knowledge about the hammer projection verify that the equations on the wikipedia page are correct? I would like to verify the transformation before making this change.
> 
> 
> 
> Ben Root
> 
> 
> 
Hi Ben,
the patch works very good! Thank you! And the hammer projection equatations in wikipedea are correct.
kind regards
Matthias

Well, I am a Gentoo user, so I was doing the usual emerge -uavDN world
which updates everything, so I don't know what exactly has changed.
What I can tell you is that I have gtk 2.20.1 and wxGtk 2.8.11. I
could try updating again (I update about every 1-2 weeks to keep
current and avoid issues that can arise when you update from older
stuff). Also, I can just use TkAgg as it works. If it is something
you are interested in, I don't mind trying some debug stuff if you let
me know what you need to debug. Otherwise - tkAgg appears to be the
way to go:) At least someone knows there is a potential problem. How
about I try a system update and let you know if I still see problems?
-C
On 2010年11月17日 19:46:34 -0600
Benjamin Root <ben...@ou...> wrote:
> On Wed, Nov 17, 2010 at 7:38 PM, Collin Day <dcd...@gm...>
> wrote:
> 
> > On 2010年11月17日 19:00:54 -0600
> > Benjamin Root <ben...@ou...> wrote:
> >
> > Another data point -
> >
> > I tried Qt4Agg - it also works interactively - ie it goes back to
> > the ipython cmd line. I also noticed when I start ipython --pylab,
> > the following error messages occur:
> >
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
> > ** Message: pygobject_register_sinkfunc is deprecated (GtkObject)
> >
> >
> Interesting. It is possible that the gtk backend might have been
> compiled against gtk development libraries that do not match your
> current gtk library. What have you updated recently, and how did you
> do it?
> 
> Ben Root

On Wed, Nov 17, 2010 at 7:38 PM, Collin Day <dcd...@gm...> wrote:
> On 2010年11月17日 19:00:54 -0600
> Benjamin Root <ben...@ou...> wrote:
>
> Another data point -
>
> I tried Qt4Agg - it also works interactively - ie it goes back to the
> ipython cmd line. I also noticed when I start ipython --pylab, the
> following error messages occur:
>
> ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
> ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
> ** Message: pygobject_register_sinkfunc is deprecated (GtkObject)
>
>
Interesting. It is possible that the gtk backend might have been compiled
against gtk development libraries that do not match your current gtk
library. What have you updated recently, and how did you do it?
Ben Root

On 2010年11月17日 19:00:54 -0600
Benjamin Root <ben...@ou...> wrote:
Another data point - 
I tried Qt4Agg - it also works interactively - ie it goes back to the
ipython cmd line. I also noticed when I start ipython --pylab, the
following error messages occur:
** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
** Message: pygobject_register_sinkfunc is deprecated (GtkObject)
-C
> On Wed, Nov 17, 2010 at 6:54 PM, Collin Day <dcd...@gm...>
> wrote:
> 
> > Either I updated something that changed Matplotlib's behavior or I
> > am missing something, but when I make a plot in ipython, control is
> > not returning to the prompt - I can't do anything until I close the
> > plot. Here is exactly what I am doing:
> >
> > ipython --pylab
> >
> > x=arange(10)
> > y=x**2
> >
> > figure()
> > plot(x,y)
> > show()
> >
> > Also, I am not sure if that is right. In the past I remember just
> > being able to type plot() and the figure came up and control went
> > back to ipython to continue. But I could be wrong.
> >
> > Then, if I want to do anything else, I have to close the window.
> > The backend I am using is WXAgg. I also noticed that if I use the
> > GTKAgg backend, control does not return to the prompt even after
> > closing the plot. I have to hit ctl-c to get the prompt back. I
> > have tried this both with ion() and ioff().
> >
> > I don't ever remember having to close the plot or hit control-c to
> > keep working. I googled and did not really see anything relevant.
> > Could anyone tell me what I am missing or what I need to do so that
> > I can plot in ipython, leave the plot up, and then continue working?
> >
> > I have matplotlib 1.0.0 and ipython 0.10.1
> >
> > Thanks for any help!
> >
> >
> Most likely, you were used to interactive mode being on. A new
> installation of matplotlib might have over-written your matplotlibrc
> file, resetting the option to False. Find your matplotlibrc file and
> change interactive to True to get the behavior you want.
> 
> I hope that helps!
> 
> Ben Root

Sorry - I should have replied to all to continue the thread on the
forum....
Begin forwarded message:
Date: 2010年11月17日 18:22:25 -0700
From: Collin Day <dcd...@gm...>
To: Benjamin Root <ben...@ou...>
Subject: Re: [Matplotlib-users] Control of thread/program not returning
to ipython after creating a plot.
On 2010年11月17日 19:00:54 -0600
Benjamin Root <ben...@ou...> wrote:
I tried that - same results. I did continue to try different backends
- TkAgg lets me call figure(), pulls up an empty figure and then I call
 plot(x,y) and the plot appears as expected. That backend is fine
 with me, but I am wondering if I have found a bug or some sort of
 interaction with GTK and / or wx. Here are snippets
 from /etc/matplotlib/matplotlibrc (when it doesn't work)
backend : WXAgg
# if you are runing pyplot inside a GUI and your backend choice
# conflicts, we will automatically try and find a compatible one for
# you if backend_fallback is True
#backend_fallback: True
interactive : True 
so I have interactive set.
-C
> On Wed, Nov 17, 2010 at 6:54 PM, Collin Day <dcd...@gm...>
> wrote:
> 
> > Either I updated something that changed Matplotlib's behavior or I
> > am missing something, but when I make a plot in ipython, control is
> > not returning to the prompt - I can't do anything until I close the
> > plot. Here is exactly what I am doing:
> >
> > ipython --pylab
> >
> > x=arange(10)
> > y=x**2
> >
> > figure()
> > plot(x,y)
> > show()
> >
> > Also, I am not sure if that is right. In the past I remember just
> > being able to type plot() and the figure came up and control went
> > back to ipython to continue. But I could be wrong.
> >
> > Then, if I want to do anything else, I have to close the window.
> > The backend I am using is WXAgg. I also noticed that if I use the
> > GTKAgg backend, control does not return to the prompt even after
> > closing the plot. I have to hit ctl-c to get the prompt back. I
> > have tried this both with ion() and ioff().
> >
> > I don't ever remember having to close the plot or hit control-c to
> > keep working. I googled and did not really see anything relevant.
> > Could anyone tell me what I am missing or what I need to do so that
> > I can plot in ipython, leave the plot up, and then continue working?
> >
> > I have matplotlib 1.0.0 and ipython 0.10.1
> >
> > Thanks for any help!
> >
> >
> Most likely, you were used to interactive mode being on. A new
> installation of matplotlib might have over-written your matplotlibrc
> file, resetting the option to False. Find your matplotlibrc file and
> change interactive to True to get the behavior you want.
> 
> I hope that helps!
> 
> Ben Root

On Wed, Nov 17, 2010 at 6:54 PM, Collin Day <dcd...@gm...> wrote:
> Either I updated something that changed Matplotlib's behavior or I am
> missing something, but when I make a plot in ipython, control is not
> returning to the prompt - I can't do anything until I close the plot.
> Here is exactly what I am doing:
>
> ipython --pylab
>
> x=arange(10)
> y=x**2
>
> figure()
> plot(x,y)
> show()
>
> Also, I am not sure if that is right. In the past I remember just being
> able to type plot() and the figure came up and control went back to
> ipython to continue. But I could be wrong.
>
> Then, if I want to do anything else, I have to close the window. The
> backend I am using is WXAgg. I also noticed that if I use the GTKAgg
> backend, control does not return to the prompt even after closing the
> plot. I have to hit ctl-c to get the prompt back. I have tried this
> both with ion() and ioff().
>
> I don't ever remember having to close the plot or hit control-c to keep
> working. I googled and did not really see anything relevant. Could
> anyone tell me what I am missing or what I need to do so that I can
> plot in ipython, leave the plot up, and then continue working?
>
> I have matplotlib 1.0.0 and ipython 0.10.1
>
> Thanks for any help!
>
>
Most likely, you were used to interactive mode being on. A new installation
of matplotlib might have over-written your matplotlibrc file, resetting the
option to False. Find your matplotlibrc file and change interactive to True
to get the behavior you want.
I hope that helps!
Ben Root

Either I updated something that changed Matplotlib's behavior or I am
missing something, but when I make a plot in ipython, control is not
returning to the prompt - I can't do anything until I close the plot.
Here is exactly what I am doing:
ipython --pylab
x=arange(10)
y=x**2
figure()
plot(x,y)
show()
Also, I am not sure if that is right. In the past I remember just being
able to type plot() and the figure came up and control went back to
ipython to continue. But I could be wrong.
Then, if I want to do anything else, I have to close the window. The
backend I am using is WXAgg. I also noticed that if I use the GTKAgg
backend, control does not return to the prompt even after closing the
plot. I have to hit ctl-c to get the prompt back. I have tried this
both with ion() and ioff().
I don't ever remember having to close the plot or hit control-c to keep
working. I googled and did not really see anything relevant. Could
anyone tell me what I am missing or what I need to do so that I can
plot in ipython, leave the plot up, and then continue working?
I have matplotlib 1.0.0 and ipython 0.10.1
Thanks for any help!

On Wed, Nov 17, 2010 at 5:37 PM, Eric Firing <ef...@ha...> wrote:
> On 11/17/2010 01:28 PM, Ognjen Ilic wrote:
> > Thanks for the help. However, when I change the matplotlibrc file I
> > get the following message
> > "Bad key "path.simplify" on line 267 in
> > /HOME/.matplotlib/matplotlibrc.
> > You probably need to get an updated matplotlibrc file from
> > http://matplotlib.sf.net/matplotlibrc or from the matplotlib source
> > distribution"
> >
> > I'd do the update but I don't have root access on the server
>
> It sounds like you have an old enough version of mpl that it does not
> support rc configuration of the path simplification. If so, your only
> option is to update mpl itself. It should be possible to build and
> install a local copy without root access, and put its location in your
> PYTHONPATH.
>
> Eric
>
>
A really simple way to do this is (from the terminal in the matplotlib
directory):
python setupegg.py install --user
Everything gets installed to your .local directory and your python
installation should find it without problems.
Ben Root