matplotlib-devel Mailing List for matplotlib

Hi there,
I just submitted a patch changing the errorhandling of Line2D on non-existant 
linestyle/marker strings. Now I realize that it obviously clashes with the 
current policy for reporting errors.
What happened before was that
 plot(...,linestyle='garbage',...)
would verbose.report_error and set linestyle to a default, while
 set_linestyle(...,linestyle='garbage')
would be silent and still set linestyle to a default.
Clearly, this is inconsistent, so there will be little argument that the 
behavior should be unified. Question is, to what?
What I would expect is, that set_linestyle raises an exception if it is called 
with the wrong arguments. This is, what I expect of any python library, no 
matter whether it offers a GUI or not. When I work in ipython at the 
commandline, I expect the errors to be displayed right there, and not be 
written to a file or displayed in some window.
Obviously, this clashes with the very existance of the 'Verbose' class, used 
to report errors which just writes errors to some file and goes on with work 
afterwards.
The verbose.report_error approach certainly is useful within the code that is 
run in the GUI-thread. Those routines that are called from outside, though, 
should rather raise exception.
Furthermore, the outside functions should do as much checking on the input as 
reasonably possible, so that errors are simpler to debug. Once some erraneous 
input has reached the internals of matplotlib, it really is hard for the user 
to guess what actually caused the error.
Ciao,
Norbert
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

>>>>> "Joe" == Joe <gar...@us...> writes:
 Joe> Hello devels, I chose to use matplotlib for a restaurant
 Joe> simulation. It supplied all the features I needed and I was
 Joe> pleasantly surprised. However the people I was doing this
 Joe> project for mentioned that the simulation slowed down to a
 Joe> crawl 10 or so minutes into the simulation. It sounded like
 Joe> a memory leak to me so I investigated and found a 100 KB/sec
 Joe> leak in Windows (via the interpreter as well as frozen with
 Joe> py2exe) as well as in Linux. I narrowed it down to a part of
 Joe> the code where I updated xlim and ylim via Axes::set_xlim,
 Joe> Axes::set_ylim. Commenting that part out yielded no leak,
So you're doing animation right? Are you using images, eg imshow? I
just fixed a memory leak in image resizing that amounts to about
200K/resize -- the changes are in CVS. Of course on windows it's hard
to test because the changes are in extension code, and require
building on win32. The instructions for building on win32 are in the
file setupext.py.
If you are not using images, another place to look is in text caching.
text layout is expensive (to support arbitrary rotations, etc). So I
cache the layout information in a dictionary "cached" in the text
module. When you change the xlim/ylim, that would trigger a new
layout and an addition to the cache. We need to add some
auto-clearing mechanisms to prevent the cache from growing w/o bound
but its not done yet. I find it hard to believe, though, that this
would leak 100kb/sec. Assuming a 20Hz frame rate, the leak is about
5kb/sec, and I don't think I'm caching that much info.
You can estimate the memory effect of the cached simply by commenting
out the line
 self.cached[key] = ret
in the matplotlib.text module.
What backend are you using? Are you refreshing the same figure data,
or creating new figures? More information would certainly help.....
 Joe> however I lost some critical functionality in my charts
 Joe> (which behave like the Windows Task Manager resource monitor
 Joe> graphs). So I really need this fixed. I will send shortly a
 Joe> test case which replicates the problem.
That would be great.
 Joe> Since the maintainer is out on vacation, I was also wondering
 Joe> if anyone knew enough about the internals of matplotlib that
 Joe> they could give me an idea of which modules (Python or
 Joe> otherwise) are affected by Axes::set_xlim and Axes::set_ylim.
I'm back. I was in Rio for a couple of weeks and have suffered a 95
degree temperature drop returning to Chicago (sigh)...
JDH