matplotlib-devel Mailing List for matplotlib

On Fri, Feb 25, 2005 at 02:04:57PM -0500, Abraham Schneider wrote:
> Hmm.. you make good points. Generally I think it is better to keep 
> everything within python when possible (plus I am not a big fan of 
> XML..). I suspect in the end this ends up being a preference issue, but 
> here is the advantage I see with XML. Suppose I have code that reads 
> data from a file, and can display that data in several different views 
> (e.g. different variables, different outlays, etc. depending on what is 
> being examined). In the past I have written a seperate python program 
> per view that I need or allowed command line parameters to be passed.
> 
> The difficulty with having separate python programs:
> * Will have to either:
> + run a different program per view I want
> + pass a python program as a parameter to run (I don't want to have 
> to edit the main program for each new view have another import .. I 
> suppose one could put them all in the same directory, but this could be 
> a hassle for quick hacks). This isn't a big deal, since I've essentially 
> already advocated this for the config files. Somehow the semantics of 
> doing so under these circumstances seems different to me, and perhaps 
> more userfriendly to provide a layout language.
> + continually reedit the same file with different parameters
> 
> On the other hand, if everything is passed on the command line, I have 
> found it is difficult to get enough specifity to plot exactly I want, 
> without requiring several lines worth of parameters.
> 
> So I see XML as a means of separating the layout of the data and 
> managing the different views, without having to touch the code at all. 
> In the end it doesn't really provide anything new, except for a 
> different method of doing the same thing.
> 
Python imports don't have to be static, you can access modules dynamically
just like you would XML files. For our web application we keep per-client
information in .py files that gets __import__'d to modify the look & feel,
setup default email addresses, etc. The modules just have to have some
agreed on names. If they have a particular function it gets called with
an object they can tweak.
ex/
def apply_custom(client_id):
 try:
 custom = __import__('client_%d' % (client_id))
 except ImportError: # nothing custom
 return
 def NOP(*args): return # do nothing function
 getattr(custom, 'alter_skin', NOP)(skin_object)
 getattr(custom, 'add_reports', NOP)(report_list)
 # etc
The upshot is that you can use python modules just like you would
use XML. They both contain markup, just different kinds.
-Jack
 

Hmm.. you make good points. Generally I think it is better to keep 
everything within python when possible (plus I am not a big fan of 
XML..). I suspect in the end this ends up being a preference issue, but 
here is the advantage I see with XML. Suppose I have code that reads 
data from a file, and can display that data in several different views 
(e.g. different variables, different outlays, etc. depending on what is 
being examined). In the past I have written a seperate python program 
per view that I need or allowed command line parameters to be passed.
The difficulty with having separate python programs:
* Will have to either:
 + run a different program per view I want
 + pass a python program as a parameter to run (I don't want to have 
to edit the main program for each new view have another import .. I 
suppose one could put them all in the same directory, but this could be 
a hassle for quick hacks). This isn't a big deal, since I've essentially 
already advocated this for the config files. Somehow the semantics of 
doing so under these circumstances seems different to me, and perhaps 
more userfriendly to provide a layout language.
 + continually reedit the same file with different parameters
On the other hand, if everything is passed on the command line, I have 
found it is difficult to get enough specifity to plot exactly I want, 
without requiring several lines worth of parameters.
So I see XML as a means of separating the layout of the data and 
managing the different views, without having to touch the code at all. 
In the end it doesn't really provide anything new, except for a 
different method of doing the same thing.
Abe
John Hunter wrote:
>My initial response to something like this, which I've seen before in
>the context of mpl, is: what is the advantage of using a XML over
>python? Except for the plot command, which specifies a read data and
>filename, everything is pretty much a literal translation of python.
>My suggestion would be to create custom python classes that build your
>figures, and use python 
>
>class PlotItem:
> def __init__(self, fn, fname, var, color, lw): 
> ... do something with it
>
>class SubplotItem:
> def __init__(self, title, pos)
> ....contains one or more plot items
>
>class FigureItem:
> def __init__(self, title)
> ... contains one or more axes items
>
> 
>fig = FigureItem(title="Hodgkin and Huxley cell")
>sub = SubplotItem(title="voltage" pos="1,1")
>fig.add_subplot(sub)
>plot = PlotItem(fn="readData" file="sim.dat", var="voltage")
>sub.add_plot(fig)
>
>and so on. Then you have the full power of python to specify your
>configuration layer. What does an XML layer buy you? I could see
>it's usefulness if you were trying to develop a GUI tool to edit and
>configure your figures....
>
>There has been some interest in having a way to save a figure state to
>an external file and open it where you left off. An XML
>representation might be useful there, in that it would ease the
>development of figure editors in a way that a pickled version would
>not.
>
>
> Abraham> p.s. I've had the traits-based config library almost done
> Abraham> for a bit .. I just haven't had time to put the last
> Abraham> finishing touches on it. I'll email it soon.
>
>Great.
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Hi. I've found myself in the position of (a) often having
 Abraham> to plot data with specific views for either debugging or
 Abraham> publication purposes. While this is often easy enough to
 Abraham> write as a python script, I've found myself either
 Abraham> rewritting the same code over again, or having to create
 Abraham> a large number of command line parameters to specify
 Abraham> exactly what type of plot is required. It occured to me
 Abraham> that it might be nice to have a seperation of data and
 Abraham> plotting (i.e. MVC) and that XML would work well for
 Abraham> these purposes (e.g. libglade and renaissance) . For
 Abraham> example, something like:
My initial response to something like this, which I've seen before in
the context of mpl, is: what is the advantage of using a XML over
python? Except for the plot command, which specifies a read data and
filename, everything is pretty much a literal translation of python.
My suggestion would be to create custom python classes that build your
figures, and use python 
class PlotItem:
 def __init__(self, fn, fname, var, color, lw): 
 ... do something with it
class SubplotItem:
 def __init__(self, title, pos)
 ....contains one or more plot items
class FigureItem:
 def __init__(self, title)
 ... contains one or more axes items
 
fig = FigureItem(title="Hodgkin and Huxley cell")
sub = SubplotItem(title="voltage" pos="1,1")
fig.add_subplot(sub)
plot = PlotItem(fn="readData" file="sim.dat", var="voltage")
sub.add_plot(fig)
and so on. Then you have the full power of python to specify your
configuration layer. What does an XML layer buy you? I could see
it's usefulness if you were trying to develop a GUI tool to edit and
configure your figures....
There has been some interest in having a way to save a figure state to
an external file and open it where you left off. An XML
representation might be useful there, in that it would ease the
development of figure editors in a way that a pickled version would
not.
 Abraham> p.s. I've had the traits-based config library almost done
 Abraham> for a bit .. I just haven't had time to put the last
 Abraham> finishing touches on it. I'll email it soon.
Great.

Hi. I've found myself in the position of (a) often having to plot data 
with specific views for either debugging or publication purposes. While 
this is often easy enough to write as a python script, I've found myself 
either rewritting the same code over again, or having to create a large 
number of command line parameters to specify exactly what type of plot 
is required. It occured to me that it might be nice to have a seperation 
of data and plotting (i.e. MVC) and that XML would work well for these 
purposes (e.g. libglade and renaissance) . For example, something like:
<pylab>
<figure title="Hodgkin and Huxley cell">
<subplot title="voltage" pos="1,1"><plot fn="readData" file="sim.dat" 
var="voltage"/></subplot>
<subplot title="m" pos="2,1">
 <plot fn="readData" file="sim.dat" var="m" color='b' linewidth="2"/>
 <plot fn="readData" file="sim.dat" var="h" color='g' linewidth="2"/>
 <plot fn="readData" file="sim.dat" var="n" color='r' linewidth="2"/>
</subplot>
</figure>
</pylab>
would be nice, and then all one would have to do is define the function 
'readData'. Most likely, if all your data files are nearly the same, you 
would only have to define 'readData' once, and then depending on what 
type of plots you wanted, you could easily change the XML doc to fit 
your needs without having to rewrite more code.
I have some code to do this, which I quickly hacked together today. I'll 
probably be working on it for my own uses, but I thought I would check 
if this is something people might be interested in having in the pylab 
library..
Abe
p.s. I've had the traits-based config library almost done for a bit .. I 
just haven't had time to put the last finishing touches on it. I'll 
email it soon.

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
> This is the continuation of an exchange in which Fernando reported a
> problem when viewing eps figures generated by mpl and included in a
> pdf file generated by latex.
Thanks John, I really appreciate you working on this right now. Unfortunately 
I'm scrambling to finish this talk, so I don't have time to switch matplotlib 
versions right now across my desktop _and_ laptop. Don't switch horses while 
crossing the river and all that.
But next week I'll look into the fix. For now, switching to pngs works OK, 
they look fine (if not perfect) under Acroread, which is all I need. As a 
side note, even if these print fine, since I use acroread for a laptop-based 
presentation via a projector, that doesn't do me much good :)
Anyway, thanks again to John and Paul for tackling this at my request. I'll 
survive with the png solution for now, and will look into the new PS option 
next week.
While on that topic: would it be possible/sensible to support at least 
sub/superscripts and symbols in the plain PS backends? Gnuplot allows you to 
switch fonts and embed symbols with the native PS symbol font, which has the 
advantage of producing tiny PS files. Here's an example of some old code of mine:
 tit_s = "N_{nod}=%s, {/Symbol e}=%1.1e, N_{blocks}=%s"
 title = tit_s % (self.nnod,self.cutoff,self.nkeys())
Not perfect, and eps-specific, but quite handy for making small EPS files with 
basic mathematical notation.
I suggest this because right now, as far as I'm concerned, the mathtext 
support is in practice of little use. Since the _whole_ string has to be $-$ 
bracketed, putting text with a bit of math doesn't work well. Most real-world 
usage of symbols in plot labels is of this kind, rather than one big equation. 
 I know about using \textrm for text, but the resulting spacing is so ugly 
that it's really not worth using.
Another option would be to get support for mathtext in substrings (e.g. 
r'Error for $\epsilon=1$' as a valid label). But I know that's hard. If you 
go down this road, for ease of parsing, you may want to require the 
beginning/end math markers to be \( \), as latex allows (but doesn't enforce).
Anyway, I'm really grateful and don't want to sound like a whiner. With time, 
I'm sure we'll be able to work out all the remaining kinks of proper labeling 
for scientific plots with math in them in an optimal manner. And again, 
thanks for all the hard work so far.
Best,
f

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
This is the continuation of an exchange in which Fernando reported a
problem when viewing eps figures generated by mpl and included in a
pdf file generated by latex.
 Paul> In acroread the fonts on page 4 look like crap, but if I
 Paul> print it, it looks fine. So the problem looks like a
 Paul> mismatch between acroread and the TTF.
I took the plunge and made a new rc param
 ps.useafm : False
if True, the ps backend will fall back on old font handling, using afm
files and not embedding true type. This of course breaks mathtext,
but does result in files that are small, and they may work better in
acroread when converted to PDF via latex. Here is simple_plot made
with useafm = False and useafm = True.
peds-pc311:~/python/projects/matplotlib> ls -l *.ps
-rw-rw-r-- 1 jdhunter jdhunter 7137 Feb 23 15:36 afm.ps
-rw-rw-r-- 1 jdhunter jdhunter 144234 Feb 23 15:35 ttf.ps
It appears to pass backend driver, though I didn't visually check
every output. It would be nice to extend this approach to allow the
user to use afm for everything but mathtext, if desired, as well as to
embed only the individual truetype glyphs as we've discussed before,
but this is a start. I didn't use the state caching with the afm
fonts since this is a system Jochen created and I don't want to break
anything, so Jochen you may want to take a look and clean it up. I'm
pretty sure I didn't break anything -- just added new functionality
that might be able to be done more efficiently.
Fernando, on another note, I believe the Cairo backend generates PS,
which you could also try. I haven't looked at it.
JDH

Hey folks, after an afternoon of mixing and matching pythons, py2exes 
and matplotlibs I was able to downgrade to a version that works.
python: 2.3.5
py2exe: 0.5.2
pygtk: 2.4.1
numeric: 23.7
numarray: 1.1.1
matplotlib: 0.65.1
My money is on something about matplotlib changed from 0.65.1 to the
current version. But having dirty build and dist directories could
have affected things as well. So the issue has been sort of resolved
for me (I can make do with the older version of matplotlib
just fine), but maybe not for someone else who needs a newer version
of the library.
Keep up the great work everyone,
Joe
Joe Garfield wrote:
> Hello all,
> 
> I still have not been able to solve this problem and need a little 
> assistance. So far I've tried every permutation
> of the -i and -p command-line options (-p matplotlib.numerix, -i 
> matplotlib.numerix.*), but to no avail. My next
> step is to see if I can rebuild the environment that I had when the 
> py2exe thing was working (downgrade all the
> versions of the involved packages). What I need in the meantime is some 
> speculation as to why this is failing.
> 
> Thanks,
> Joe
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hello all,
I still have not been able to solve this problem and need a little 
assistance. So far I've tried every permutation
of the -i and -p command-line options (-p matplotlib.numerix, -i 
matplotlib.numerix.*), but to no avail. My next
step is to see if I can rebuild the environment that I had when the 
py2exe thing was working (downgrade all the
versions of the involved packages). What I need in the meantime is some 
speculation as to why this is failing.
Thanks,
Joe

John,
When running coutour_demo.py with the Cairo backend I get:
 File "matplotlib/figure.py", line 338, in draw
 for a in self.axes: a.draw(renderer)
 File "matplotlib/axes.py", line 1307, in draw
 self.legend_.draw(renderer)
 File "matplotlib/legend.py", line 181, in draw
 h.draw(renderer)
 File "matplotlib/lines.py", line 266, in draw
 gc.set_foreground(self._color) # problem
 File "/matplotlib/backends/backend_cairo.py", line 421, in set_foreground
 self.ctx.set_rgb_color(*self._rgb)
TypeError: Context.set_rgb_color() takes exactly 3 arguments (4 given)
It looks to like the frontend (lines.py) is working with rgba colors
and passing the rgba color to the backend which is expecting rgb color.
colors.colorConverter.to_rgb(fg) is also a problem because for rgba input
it returns rgba not rgb.
One solution would be to change the last lines of colorConverter.to_rgb(fg)
from
 self.cache[arg] = color
 return color
to
	color = color[0:3]
 self.cache[arg] = color
 return color
To ensure that to_rgb() actually gives rgb and not rgba.
What do you think?
Steve

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Hi All, I've started playing around with traits in what I
 Andrew> think is the logical first step -- the _transforms
 Andrew> extension module.
I've been wondering about this myself. It is not a necessary step,
but may be desirable. Not necessary because we could use traits for
things like artist properties (line widths, edge colors and the like)
where the GUI editor features will be useful to many, and keep the
transforms implementation traits free. But it may be desirable
because the transform framework was designed to solve many of the
problems traits solves and is currently a bit hairy -- traits may
offer us a chance to clean the transforms implementation and
interface in a way that is user extensible.
traits and mpl transforms take different approaches to solving the
problem of keeping the transform updated with respect to things like
changes in window size and view limits, and if we were to refactor the
transforms architecture to use traits I think a total rewrite would be
appropriate. I wouldn't focus on a class by class rewrite (Value,
Point, Interval, Bbox) because this scheme was designed to support the
LazyValue architecture which would become obsolete. Rather I would do
a rewrite that caters to the strength of traits. A sketch in this
direction is included below.
 Andrew> Before I go too far, a couple of questions arising from
 Andrew> the fact that many of the extension types (Point, Bbox,
 Andrew> ...) have C members. The biggest concern is that a simple
 Andrew> re-implementation in traits would move all this to a
 Andrew> Python level and thus presumably slow things down. Is
 Andrew> this perceived to be a significant issue?
Basically, with traits you would use the observer pattern to update
the affines when display or view limits change. The mpl approach is
to defer evaluation of the arithmetic until render time (lazy values
with arithmetic ops overloaded). Performance is a problem here --
this was originally done in python and was too slow. But with an
observer pattern, you wouldn't need the extension code since you
wouldn't be doing lazy evaluation at all.
 
I think the basic interface should be:
 A transformation is an (optional) nonlinear transform that takes an
 x,y pair and returns an x,y pair in cartesian coords and also
 supplies an affine transformation to map these cartesian coords to
 display space.
Transformation gurus, does this cover the spectrum? 
One thing that is nice about the current implementation, which does
the nonlinear part in extension code, is that it allows us to
effectively and efficiently deal with nan even thought there isn't
consistent support for these in the python / numerix. Eg in
backend_agg draw_lines
 for (size_t i=0; i<Nx; ++i) {
 thisx = *(double *)(xa->data + i*xa->strides[0]);
 thisy = *(double *)(ya->data + i*ya->strides[0]);
 
 
 if (needNonlinear)
 try {
	mpltransform->nonlinear_only_api(&thisx, &thisy);
 }
 catch (...) {
	moveto = true;
	continue;
 }
Basically, when the transform throws a domain error, the point is
skipped and the moveto code is set [ C++ mavens, I know the catch(...)
thing is bad form but was added as a quick workaround with gcc 3.4.x
was giving us hell trying to catch the std::domain_error explicitly. ]
To do this at the numstar level would require an extra pass through
the data (once for the transform and once for the draw_lines) and we
would need some support for illegal values, either as nan or as a
masked array. In the case of log transforms, to take a concrete
example, preprocessing the data to screen out the non-positive elements
would probably require an additional pass still. So for performance
reasons, there is something to be said for doing the nonlinear part in
extension code. For easy extensibility though, the converse is
certainly true. Perhaps it's possible to have the best of both
worlds.
In any case, here is the start of how I would define some of the core
objects (Bbox and Affine). Value and Point would disappear as they
arose from the lazy value scheme. Interval would be easy to define
using an observer pattern on the Bbox.
from matplotlib.enthought.traits import Trait, HasTraits, Float
from matplotlib.numerix.mlab import amin, amax, rand
class Bbox(HasTraits):
 left = Float
 bottom = Float
 right = Float
 top = Float
 def __init__(self, l=0., b=0., r=1., t=1.):
 HasTraits.__init__(self)
 self.left = l
 self.bottom = b
 self.right = r
 self.top = t
 
 def width(self):
 return self.right - self.left
 def height(self):
 return self.top - self.bottom
 def update_numerix(self, x, y):
 'update the bbox to make sure it contains x and y'
 # This method is used to update the datalim; the python
 # impl. requires 4 passes through the data; the extension code
 # version requires only one loop. But we could make provide
 # an extension code helper function, eg with signature
 # minx,miny, maxx, maxy = _get_bounds(x,y)
 # if we want
 minx = amin(x)
 maxx = amax(x)
 miny = amin(y)
 maxy = amax(y)
 if minx<self.left: self.left = minx
 if maxx>self.right: self.right = maxx
 if miny<self.bottom: self.bottom = miny
 if maxy>self.top: self.top = maxy
 # the current extension code also tracks the minposx and
 # minposy for log transforms
class ProductBbox(Bbox):
 """
 Product of bounding boxes - mainly used as specialty bbox for axes
 where the bbox1 is in relative (0,1) coords, bbox2 is in display.
 The axes pixel bounds are maintained as the product of these two
 boxes
 """
 bbox1 = Bbox
 bbox2 = Bbox
 def __init__(self, bbox1, bbox2):
 Bbox.__init__(self)
 self.bbox1 = bbox1
 self.bbox2 = bbox2
 self.update()
 bbox1.on_trait_change(self.update)
 bbox2.on_trait_change(self.update)
 def update(self, *args):
 self.left = self.bbox1.left * self.bbox2.left
 self.right = self.bbox1.right * self.bbox2.right
 self.bottom = self.bbox1.bottom * self.bbox2.bottom
 self.top = self.bbox1.top * self.bbox2.top
class Affine(HasTraits):
 a = Float
 b = Float
 c = Float
 d = Float
 tx = Float
 ty = Float
 def __repr__(self):
 return ', '.join(['%1.3f'%val for val in (self.a, self.b,
 self.c, self.d,
 self.tx, self.ty)])
class BboxAffine(Affine):
 bbox1 = Bbox
 bbox2 = Bbox
 def __init__(self, bbox1, bbox2):
 Affine.__init__(self)
 self.bbox1 = bbox1
 self.bbox2 = bbox2
 self.update()
 bbox1.on_trait_change(self.update)
 bbox2.on_trait_change(self.update)
 def update(self, *args):
 sx = self.bbox2.width()/self.bbox1.width()
 sy = self.bbox2.height()/self.bbox1.height()
 tx = -self.bbox1.left*sx + self.bbox2.left
 ty = -self.bbox1.bottom*sy + self.bbox2.bottom 
 self.a = sx
 self.b = 0.
 self.c = 0.
 self.d = sy
 self.tx = tx
 self.ty = ty
viewbox = Bbox(1, 2, 3, 3) # data coords
axfrac = Bbox(0.1, 0.1, 0.8, 0.8) # fraction
figbox = Bbox(0,0,400,400) # pixels
axbox = ProductBbox(axfrac, figbox)
axtrans = BboxAffine(viewbox, axbox)
print axtrans
# now to a figure resize
figbox.right = 600
figbox.bottom = 500
# and change the view lim
viewbox.update_numerix(5*rand(100), 5*rand(100))
# and check the affine
print axtrans

Hi All,
I've started playing around with traits in what I think is the logical 
first step -- the _transforms extension module.
Before I go too far, a couple of questions arising from the fact that 
many of the extension types (Point, Bbox, ...) have C members. The 
biggest concern is that a simple re-implementation in traits would move 
all this to a Python level and thus presumably slow things down. Is 
this perceived to be a significant issue?
If yes, then there seem two potential options to re-gain speed from the 
C level.
Option A: Python classes derive from traits.HasTraits to implement 
Point, Bbox, etc. but each would have a self._shadow member which is an 
extension type with its own internal values needed by other C level code 
(potentially including a copy of the Python-level attributes). Using 
trait's notification abilities, it shouldn't be any problem to keep the 
shadow in sync with the Python level, and C code could set attributes as 
needed through the Python interface. This option seems slightly messy, 
but probably workable. Also, it would have the benefit of keeping 
things mostly in Python, at least before optimization.
Option B: re-tool the traits machinery to support extension types. I've 
thought about two ways to do this and neither seem appealing. Both 
involve significant changes to the traits infrastructure because for 
definitions to be available to C without the equivalent of a dict 
lookup, they would have to be made at compile time. Method 1: make 
multiple extenstion types that derive from has_traits_object (defined in 
ctraits.c) rather than PyObject and re-jig the higher level machinery 
for each of these new extension types. Method 2: drop traits itself 
and implement traits-like functionality (in CXX?). However appealing 
this option is in concept, both of these proposed methods would probably 
require some deep Python magic that I'm not sure we should bother with 
(even if we presume we have the necessary skills).
I'm attaching a couple of files: First is the beginnings of a new 
transforms.py which mainly includes the data structures and 
constructors. I actually wrote this before the above regarding matured, 
so comments regarding what is and is not needed from the Python level 
are welcome. (What should be hidden in just the _shadows?) Also, 
regions marked XXX reflect my uncertainty about other issues -- 
clarification on these will be appreciated. The second file I'm 
including is polynomial.py, a pure-Python proof-of-concept 
implementation of the shadow idea.
What do folks think?

>>>>> "Stefan" == Stefan Kuzminski <pon...@ya...> writes:
 Stefan> Hi, When I try to use Psyco with matplotlib-0.71 I get the
 Stefan> error below.
 Stefan> http://psyco.sourceforge.net/
 Stefan> self.figwidth*self.dpi, TypeError: unsupported operand
 Stefan> type(s) for *: 'BinOp' and 'BinOp'
 Stefan> Any ideas? thanks, Stefan
I don't have much experience with pysco. All I can add is that BinOp
is an extension code class that derives from LazyValue, and is
designed to defer evaluation of scalars and operations until needed.
The point of this is to allow you to do things like window resizes and
have all your transforms update w/o needing an observer pattern. The
classes are described in a bit more detail in
http://matplotlib.sf.net/matplotlib.transforms.html .
Does pyscho play well with extension modules in general? Surely it
must. It's possible that this is revealing an error in mpl code,
pycxx code, or it may be on the psyco side. I would be willing to
work with you to compose a minimal example if you want to pursue it.
You could start with
 from matplotlib.transforms import Value
 v1 = Value(1)
 v2 = Value(2)
 v3 = v1*v2
 v1.set(2)
 print v3.get() # should be 4
JDH

Hi,
When I try to use Psyco with matplotlib-0.71 I get the error below.
http://psyco.sourceforge.net/
 File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line
808, in gca
 return gcf().gca(**kwargs)
 File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line
817, in gcf
 return figure()
 File "/usr/lib/python2.3/site-packages/matplotlib/pylab.py", line
786, in figure
 figManager = new_figure_manager(num, figsize, dpi, facecolor,
edgecolor, frameon)
 File
"/usr/lib/python2.3/site-packages/matplotlib/backends/backend_agg.py",
line 276, in new_figure_manager
 thisFig = Figure(*args, **kwargs)
 File "/usr/lib/python2.3/site-packages/matplotlib/figure.py", line
45, in __init__
 self.ur = Point( self.figwidth*self.dpi,
TypeError: unsupported operand type(s) for *: 'BinOp' and 'BinOp'
Any ideas? 
thanks,
Stefan
		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 

John,
This sounds great! Let me know if you need any help from us.
FYI: here is the fix for the Qt front end status bar not having an initial 
message (so it doesn't appear until a message is displayed).
In backend_qt.py, add this line to the ctor for NavigationToolbar2QT:
self.window.statusBar.message( " " )
so the ctor looks like this:
 def __init__( self, canvas, window ):
 self.window = window
 self.canvas = canvas
 qt.QToolBar.__init__( self, "Navigator2", window, qt.Qt.DockBottom )
 NavigationToolbar2.__init__( self, canvas )
 # If we don't do this, the status bar is hidden until needed.
 self.window.statusBar.message( " " )
Ted
At 07:40 AM 2/15/2005, John Hunter wrote:
>error_msg and verbose.report_error are banished. In their place use
>exceptions and warnings.warn. I ported all existing matplotlib
>frontend and backend code, but please check your respective backends
>and diff them against 0.72 to make sure you agree with what I did.
>
>I left error_msg_gtk, error_msg_wx and friends for internal backend
>use (they aren't imported or used in any other part of mpl code).
>Thus proper (in my view) uses like
>
>
> agg = self.switch_backends(FigureCanvasAgg)
> try: agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
> except IOError, msg:
> error_msg_gtk('Failed to save\nError message: %s'%(msg,), self)
>
>are still in the code base.
>
>Hope this removes one source of confusion. If people think we need to
>layer some more sophisticated error handling on top of this, I'm open.
>But at least we are now starting from a clean slate with exceptions
>used consistently throughout.
>
>JDH
>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

error_msg and verbose.report_error are banished. In their place use
exceptions and warnings.warn. I ported all existing matplotlib
frontend and backend code, but please check your respective backends
and diff them against 0.72 to make sure you agree with what I did.
I left error_msg_gtk, error_msg_wx and friends for internal backend
use (they aren't imported or used in any other part of mpl code).
Thus proper (in my view) uses like
 agg = self.switch_backends(FigureCanvasAgg)
 try: agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
 except IOError, msg:
 error_msg_gtk('Failed to save\nError message: %s'%(msg,), self)
are still in the code base.
Hope this removes one source of confusion. If people think we need to
layer some more sophisticated error handling on top of this, I'm open.
But at least we are now starting from a clean slate with exceptions
used consistently throughout.
JDH

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
 Ted> I would vote for not having GUI messages being popped up from
 Ted> a script. A quick poll of our users also indicates that they
 Ted> expect script errors to be like python and appear in the
 Ted> script.
Agreed -- what designed to ease the life of point and click windows
users has turned into a monster that is bogging us down.
 Ted> Could we set some type of option in the config file that
 Ted> would allow either behavior?
No, afraid not. All that crappy error handling cruft is going in the
heap. It's exceptions all the way through.
I've actually already banished every usage of error_msg from my local
tree. I think verbose.report_error should go the same way -- all
opposed, say "Nay"!
Assuming that report_error should die too, the remaining question is
how to best handle deprecation or non fatal errors 
or something where we want to warn but fall back on a default
behavior. My vote is
 import warnings
 warnings.warn('This function is deprecated')
JDH

I like the idea of keeping pylab simpler. It's too bad there is no easy 
way to handle executable python code from Windows. Of course, windows 
users could write a small wrapper that traps exceptions, prints them, and 
then waits for a keypress - but that might be too much to ask. I think 
about it some more...
I would vote for not having GUI messages being popped up from a script. A 
quick poll of our users also indicates that they expect script errors to be 
like python and appear in the script.
One thing to think about is that if you dump all errors into a GUI, you 
limit the ability to use matplotlib in some applications. For example, 
we're considering writing a real-time plotting application that reads data 
from the network and keeps a screen updated of the current status (in this 
case, we want to plot real-time data read from spacecraft telemetry) for 
several teams to look at. This application needs to be very robust and 
handle errors explicitly so that it remains running at all times. It's 
generally going to be displayed on a monitor away from the computer for 
people to see.
Since this is an automated system, it could end up trying to executing some 
plot command that is invalid (the down link data sometimes becomes 
corrupted for example). In this case, we want to catch the MPL exception 
and discard the last data packet or do some other type of data 
handling. If the error pops up a dialog, then my program is basically done 
for because there is no user to click the OK button.
Could we set some type of option in the config file that would allow either 
behavior?
Ted
At 01:43 PM 2/14/2005, John Hunter wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
> Ted> OK - I think I've read most of those messages and had a few
> Ted> comments/ideas. Soapbox mode on: Please don't change the
> Ted> system exception hook. Matplotlib (MPL) is not an
> Ted> application, it's a library. Libraries should never change
> Ted> global behavior - only applications. By changing global
> Ted> behavior you severely limit how and where your library can be
> Ted> used by others. Soapbox mode off.
>
>Point taken. One might view the pylab interface as an application,
>but I won't quibble.
>
> Ted> I wonder if it helps to think about errors from a different
> Ted> stand point. For example, I can think of two high level
> Ted> views that might help. Users interact with MPL either
> Ted> through the Python command line (via typing or scripts) or
> Ted> through GUI front ends.
>
> Ted> 1) A python function is called which has an error (or
> Ted> something it calls has an error, etc, etc). In this case, if
> Ted> the function throws an exception, python will propagate the
> Ted> exception normally. If you're typing something on the prompt
> Ted> or running a script, the exception get's printed with a trace
> Ted> back. Very useful and very normal for Python.
>
>There is a wrinkle here. On win32 (or another platform that binds
>python scripts to an executable), you might double click on a script
>
> from pylab import *
> semilogy([0,1,2,3])
> show()
>
>In pre 0.72 mpl, this would throw an exception. On windows, if you
>double clicked this script, a stdout window would launch and die
>before you could read the traceback -- very annoying. That's the
>primary reason I tried to catch exceptions in the pylab interface and
>forward them on to the error_msg handler function. But the current
>impl. is admittedly broken. Do you have a suggestion for how to
>handle this case?
>
>We could do something like this: all GUIs define a function
>show_message. This pops up a message dialog with a single OK button.
>pylab dies the following
>
>
>def plot(*args, **kwargs):
> # allow callers to override the hold state by passing hold=True|False
> b = ishold()
> h = popd(kwargs, 'hold', None)
> if h is not None:
> hold(h)
> try:
> ret = gca().plot(*args, **kwargs)
> except:
> msg = ...get the traceback as string ...
> show_message(msg)
> hold(b)
> ...rethrow the same exception....
> else:
> try: draw_if_interactive()
> except:
> msg = ...get the traceback as string...
> show_message(msg)
> hold(b)
> ...rethrow the same exception....
>
> hold(b)
> return ret
>
>Someone please remind me how to rethrow the last exception --
>Fernando?
>
>Or we could just ignore it and let win32 users who are double clicking
>scripts die the painful death they deserve. It would certainly make
>for cleaner pylab code.
>
> Ted> - Error trying to save the plot to the image file 'plot.png'.
> Ted> - Error in the automatic plot layout algorithm. - Error in
> Ted> setting the size of the plot region. The inputs size of
> Ted> [-10, 200] is invalid.
>
>This gives you more diagnostic information in that you get helpful
>messages at each level, but the standard traceback gives you all the
>levels, no?
>
>JDH
Ted Drain Jet Propulsion Laboratory ted...@jp... 

John,
Looks like that ctor was added in 3.2 of qt. Looking back through 3.0, I 
think you should be able to just change the line to look like this:
a = qt.QAction( text, qt.QIconSet( image ), text,
 qt.QKeySequence('M'), self.window )
which is a ctor supported by even version 2.3 of qt.
We tend to keep up w/ the latest versions of Qt pretty regularly. I may 
have to keep an old Qt/PyQt build around to test this stuff against...
Ted
At 02:08 PM 2/14/2005, John Hunter wrote:
>With the updated qtagg backend, which worked fine on my OSX box but I
>didn't test on my linux box, I get an error when trying to run a qtagg
>plot (the previous backend does work on this box, so I think my qt
>install is OK)
>
>The offending part is "argument 1" of
>
> a = qt.QAction( qt.QIconSet( image ), text, qt.QKeySequence('M'),
> self.window )
>
>
>peds-pc311:~/python/projects/matplotlib> python examples/simple_plot.py 
>-dQtAgg --verbose-helpful
>matplotlib data path /usr/local/share/matplotlib
>loaded rc file /home/jdhunter/python/projects/matplotlib-cvs/.matplotlibrc
>matplotlib version 0.72
>verbose.level helpful
>interactive is False
>platform is linux2
>numerix Numeric 23.6
>font search path ['/usr/local/share/matplotlib']
>loaded ttfcache file /home/jdhunter/.ttffont.cache
>Could not load matplotlib icon: 'module' object has no attribute 
>'window_set_default_icon_from_file'
>backend QtAgg version 0.9
>Traceback (most recent call last):
> File "examples/simple_plot.py", line 5, in ?
> figure(1)
> File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 
> 828, in figure
> figManager = new_figure_manager(num, figsize, dpi, facecolor, 
> edgecolor, frameon)
> File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qtagg.py", 
> line 25, in new_figure_manager
> return FigureManagerQT( canvas, num )
> File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py" 
> , line 155, in __init__
> self.toolbar = NavigationToolbar2QT( canvas, self.window )
> File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py" 
> , line 191, in __init__
> NavigationToolbar2.__init__( self, canvas )
> File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backend_bases.py", 
> line 896, in __init__
> self._init_toolbar()
> File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py" 
> , line 206, in _init_toolbar
> self.window )
> File "/usr/local/lib/python2.3/site-packages/qt.py", line 67, in __init__
> libqtc.sipCallCtor(216,self,args)
>TypeError: Argument 1 of QAction() has an invalid type
>
>
>peds-pc311:~/python/projects/matplotlib> python
>Python 2.3.3 (#2, Apr 13 2004, 17:41:29)
>[GCC 3.3.3] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
> >>> import qt
> >>> qt.PYQT_VERSION
>199936
>
>
>Also, the original intent of the backend_version variable was to
>report version info for the underlying toolkit. Eg
>
> backend_version = qt.PYQT_VERSION
>
>the backend is assumed to have the same version as the mpl parent.
>
>JDH
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

John Hunter wrote:
> Someone please remind me how to rethrow the last exception --
> Fernando?
try:
 foo
except E:
 print 'I caught E, now I will raise it'
 raise
Best,
f

With the updated qtagg backend, which worked fine on my OSX box but I
didn't test on my linux box, I get an error when trying to run a qtagg
plot (the previous backend does work on this box, so I think my qt
install is OK)
The offending part is "argument 1" of
 a = qt.QAction( qt.QIconSet( image ), text, qt.QKeySequence('M'),
 self.window )
peds-pc311:~/python/projects/matplotlib> python examples/simple_plot.py -dQtAgg --verbose-helpful
matplotlib data path /usr/local/share/matplotlib
loaded rc file /home/jdhunter/python/projects/matplotlib-cvs/.matplotlibrc
matplotlib version 0.72
verbose.level helpful
interactive is False
platform is linux2
numerix Numeric 23.6
font search path ['/usr/local/share/matplotlib']
loaded ttfcache file /home/jdhunter/.ttffont.cache
Could not load matplotlib icon: 'module' object has no attribute 'window_set_default_icon_from_file'
backend QtAgg version 0.9
Traceback (most recent call last):
 File "examples/simple_plot.py", line 5, in ?
 figure(1)
 File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 828, in figure
 figManager = new_figure_manager(num, figsize, dpi, facecolor, edgecolor, frameon)
 File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qtagg.py", line 25, in new_figure_manager
 return FigureManagerQT( canvas, num )
 File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", line 155, in __init__
 self.toolbar = NavigationToolbar2QT( canvas, self.window )
 File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", line 191, in __init__
 NavigationToolbar2.__init__( self, canvas )
 File "/usr/local/lib/python2.3/site-packages/matplotlib/backend_bases.py", line 896, in __init__
 self._init_toolbar()
 File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", line 206, in _init_toolbar
 self.window )
 File "/usr/local/lib/python2.3/site-packages/qt.py", line 67, in __init__
 libqtc.sipCallCtor(216,self,args)
TypeError: Argument 1 of QAction() has an invalid type
peds-pc311:~/python/projects/matplotlib> python
Python 2.3.3 (#2, Apr 13 2004, 17:41:29)
[GCC 3.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import qt
>>> qt.PYQT_VERSION
199936
Also, the original intent of the backend_version variable was to
report version info for the underlying toolkit. Eg
 backend_version = qt.PYQT_VERSION
the backend is assumed to have the same version as the mpl parent.
JDH

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
 Ted> OK - I think I've read most of those messages and had a few
 Ted> comments/ideas. Soapbox mode on: Please don't change the
 Ted> system exception hook. Matplotlib (MPL) is not an
 Ted> application, it's a library. Libraries should never change
 Ted> global behavior - only applications. By changing global
 Ted> behavior you severely limit how and where your library can be
 Ted> used by others. Soapbox mode off.
Point taken. One might view the pylab interface as an application,
but I won't quibble.
 Ted> I wonder if it helps to think about errors from a different
 Ted> stand point. For example, I can think of two high level
 Ted> views that might help. Users interact with MPL either
 Ted> through the Python command line (via typing or scripts) or
 Ted> through GUI front ends.
 Ted> 1) A python function is called which has an error (or
 Ted> something it calls has an error, etc, etc). In this case, if
 Ted> the function throws an exception, python will propagate the
 Ted> exception normally. If you're typing something on the prompt
 Ted> or running a script, the exception get's printed with a trace
 Ted> back. Very useful and very normal for Python.
There is a wrinkle here. On win32 (or another platform that binds
python scripts to an executable), you might double click on a script
 from pylab import *
 semilogy([0,1,2,3])
 show()
In pre 0.72 mpl, this would throw an exception. On windows, if you
double clicked this script, a stdout window would launch and die
before you could read the traceback -- very annoying. That's the
primary reason I tried to catch exceptions in the pylab interface and
forward them on to the error_msg handler function. But the current
impl. is admittedly broken. Do you have a suggestion for how to
handle this case?
We could do something like this: all GUIs define a function
show_message. This pops up a message dialog with a single OK button.
pylab dies the following
def plot(*args, **kwargs):
 # allow callers to override the hold state by passing hold=True|False
 b = ishold()
 h = popd(kwargs, 'hold', None)
 if h is not None:
 hold(h)
 try:
 ret = gca().plot(*args, **kwargs)
 except:
 msg = ...get the traceback as string ...
 show_message(msg)
 hold(b)
 ...rethrow the same exception.... 
 else:
 try: draw_if_interactive()
 except:
 msg = ...get the traceback as string...
 show_message(msg)
 hold(b)
 ...rethrow the same exception.... 
 
 hold(b)
 return ret
Someone please remind me how to rethrow the last exception --
Fernando?
Or we could just ignore it and let win32 users who are double clicking
scripts die the painful death they deserve. It would certainly make
for cleaner pylab code.
 Ted> - Error trying to save the plot to the image file 'plot.png'.
 Ted> - Error in the automatic plot layout algorithm. - Error in
 Ted> setting the size of the plot region. The inputs size of
 Ted> [-10, 200] is invalid.
This gives you more diagnostic information in that you get helpful
messages at each level, but the standard traceback gives you all the
levels, no?
JDH

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Wow, that makes life much easier! I'll get started on
 Abraham> re-porting the new style config library to use your
 Abraham> modified Traits2.
As I mentioned, I've been talking with the enthought folks about where
traits should live in matplotlib, and they suggested
matplotlib.enthought.traits, because
 * it's important to have traits live inside of an enthought directory
 because enthought.traits import statements are widely used in their
 UI code, and this will help us keep our code in sync with theirs.
 * because we have a stripped down version missing
 lots-o-functionality, it shouldn't go into site-packages/enthought
 because that will screw up folks who have a regular enthought
 install
So I added the core enthought traits tree (minus UI) to CVS -- once
the mirrors update (tick, tock, tick, tock), you can do
 from matplotlib.enthought.traits import HasTraits, etc.
Dave Morrill is working on a null UI (like backend_template), so that
we can develop UI functionality if we want to but it will only work on
some backends (currently WX). The other backends can fall back on the
null UI. Michel Sanner has expressed some interest in having his
group repair the currently defunct Tk traits backend. Now if we can
just get Steve to do GTK, Gregory to do FLTK and Ted and friends to do
QT, we could have a very nice way to manipulate plot attributes and rc
configuration through the GUI. But that is a story for another
day....
JDH

OK - I think I've read most of those messages and had a few comments/ideas.
Soapbox mode on:
Please don't change the system exception hook. Matplotlib (MPL) is not an 
application, it's a library. Libraries should never change global behavior 
- only applications. By changing global behavior you severely limit how 
and where your library can be used by others.
Soapbox mode off.
I wonder if it helps to think about errors from a different stand 
point. For example, I can think of two high level views that might 
help. Users interact with MPL either through the Python command line (via 
typing or scripts) or through GUI front ends.
1) A python function is called which has an error (or something it calls 
has an error, etc, etc). In this case, if the function throws an 
exception, python will propagate the exception normally. If you're typing 
something on the prompt or running a script, the exception get's printed 
with a trace back. Very useful and very normal for Python.
2) A GUI widget calls a function which has an error. If the function 
throws an exception, the GUI should trap that exception and show a dialog 
or whatever is appropriate for that GUI.
So I guess I'm wondering what happens if we just throw standard Python 
exceptions for all errors? From the Python interface you get normal Python 
behavior regardless of the front end (Tk,Qt,Gtk,Agg,etc). If you executed 
some operation from the front end (like clicking the save file dialog in 
the toolbar), you get a GUI error message like any normal GUI. Is this too 
simple of a view?
As an aside, we've found that using error stack classes work very well in 
exception error handling. Most of our code throws an error stack class 
which holds an array of error messages. This way you can trap errors and 
add an error message with context information at various levels. Many 
times errors happen at the lowest levels and you don't really know why that 
function was called.
As a completely contrived example (and probably stupid), let's say you were 
saving a plot to an image and the plot had to resize/re-render to get to 
the right image format. You might get an error back that looks like this:
- Error trying to save the plot to the image file 'plot.png'.
- Error in the automatic plot layout algorithm.
- Error in setting the size of the plot region. The inputs size of [-10, 
200] is invalid.
I realize this example doesn't make a lot of sense but hopefully it gives 
you some idea what you can do. In this case the lowest level function 
which sets the size of the region decided that the inputs were invalid. If 
you just propagate that error to the user, they may not have any idea why 
that function was called in the first place. So the higher level functions 
do a try...except loop where they add context messages to the error and 
then re-throw it. This has really helped our users get useful error 
messages when something goes wrong at the lowest level.
I don't know if that makes any sense or would help with error reporting in 
MPL so feel free to ignore it completely. It was just something that has 
helped us a lot in using exceptions to provide useful messages to people.
Ted
At 11:16 AM 2/14/2005, John Hunter wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
> Ted> Also, I'm a little confused about the backends use of the
> Ted> 'error_msg' function. Many of the backends import this
> Ted> function from backend_bases but then change that names
> Ted> definition to a local copy (see backend_gtk,
> Ted> backend_template, backend_wx). This seems wrong or at least
> Ted> more confusing that it needs to be. I don't think a script
> Ted> should explicitly import something with one name and then
> Ted> change the name to point to a local variable.
>
>We're a little confused too :-)
>
>The error_msg function was initially designed to provide a way to get
>error messages up to the GUI, otherwise they might disappear into
>stderr, stdout. However, the framework has caused nothing but grief
>and confusion and needs to die. It has lived this long simply because
>noone has found the time to kill it. The system exit in the default
>error message function was meant to be used by image backends with the
>reasoning that if you get an error on an image backend, there is no
>point in trying to continue. But now I see the unintended
>consequences of this decision when we mix image and gui backends, as
>in qt agg.
>
>There have been prolonged discussions on the topic before. See for
>example the "propagation of errors thread at CVS
>
>http://sourceforge.net/mailarchive/forum.php?forum_id=36187&max_rows=100&style=threaded&viewmonth=200411
>
>
>where we almost reach a consensus and then promptly repress the
>subject for a few more months. Last time we left off, I think I
>suggested that we should kill error message and use exception hooks to
>get the exceptions into the GUI. Steve tried to implement something
>like this for GTK -- I can't remember what the final result was.
>
>
>
>I think a good place to start would be to remove all instances of
>error_msg* from the mpl front end and backend code, and then see where
>we are. Any major problems with that?
>
>JDH
Ted Drain Jet Propulsion Laboratory ted...@jp... 

matplotlib-0.72 is up at the sourceforge site. Note that there have
been some signficant changes at the extension code level. If you get
crashes or segfaults on import or usage, try deleting the "build"
subsirectory and site-packages/matplotlib before reinstalling to
insure a clean install.
 - heavy optimizations in line marker drawing eg plot(x,y,'+') or any
 other line marker. Here are some numbers, where N is the number
 of symbols
 
 0.71 0.72 speedup
 -----------------------------------
 N = 1000 | 0.24s | 0.13s | 1.85x
 N = 5000 | 0.68s | 0.19s | 3.57x
 N = 10000 | 1.17s | 0.28s | 4.19x
 N = 50000 | 5.30s | 0.60s | 8.89x
 N = 100000 | 10.02s | 0.70s | 14.31x
 N = 500000 | 48.81s | 2.32s | 21.03x
 - lots of work making log plots "just work". You can toggle log y
 axes with the 'l' command -- nonpositive data are simply ignored
 and no longer raise exceptions. log plots should be a lot faster
 and more robust
 - fixed a contour bug for unequal sized arrays and made the syntax
 matlab compatible -- see http://matplotlib.sf.net/API_CHANGES
 - alpha version of QTAgg backend -- note the licensing issue of QT is
 murky since QT is dual licensed. If you are shipping a commercial
 product with matplotlib you may want to remove the qt backend to be
 on the safe side.
 - matshow for displaying arrays with proper aspect ratio -- see
 http://matplotlib.sf.net/matplotlib.pylab.html#-mathshow
 - new examples/interactive.py which shows you how to use matplotlib
 in a custom gtk shell
 - shared axes for two scale and ganged plots -- you can set sharex on
 and axis and multiple subpolots will pan and zoom together. See
 http://matplotlib.sf.net/examples/shared_axis_demo.py - Thanks Baptiste!
 - Default key presses over axes: 'g' toggles grid, 'l' toggles logy
 - little features: calls to subplot with overlap other subplots now
 delete the overlapped subplot, load and save work with file and
 handles gzipped files transaparently, small PS optimizations, gtk
 figure resizing more flexible
 - little bug fixes: contour datalim and unequal sized array bugs,
 mx2num, added missing mathtext symbols, fonts in mathtext
 super/subscripts, contour works with interactive changes in cmaps,
 clim
Special thanks to Fernando Perez for many CVS bug reports, feature
suggestions and contributions.
http://matplotlib.sf.net
JDH

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
 Ted> Also, I'm a little confused about the backends use of the
 Ted> 'error_msg' function. Many of the backends import this
 Ted> function from backend_bases but then change that names
 Ted> definition to a local copy (see backend_gtk,
 Ted> backend_template, backend_wx). This seems wrong or at least
 Ted> more confusing that it needs to be. I don't think a script
 Ted> should explicitly import something with one name and then
 Ted> change the name to point to a local variable.
We're a little confused too :-)
The error_msg function was initially designed to provide a way to get
error messages up to the GUI, otherwise they might disappear into
stderr, stdout. However, the framework has caused nothing but grief
and confusion and needs to die. It has lived this long simply because
noone has found the time to kill it. The system exit in the default
error message function was meant to be used by image backends with the
reasoning that if you get an error on an image backend, there is no
point in trying to continue. But now I see the unintended
consequences of this decision when we mix image and gui backends, as
in qt agg.
There have been prolonged discussions on the topic before. See for
example the "propagation of errors thread at CVS
http://sourceforge.net/mailarchive/forum.php?forum_id=36187&max_rows=100&style=threaded&viewmonth=200411
where we almost reach a consensus and then promptly repress the
subject for a few more months. Last time we left off, I think I
suggested that we should kill error message and use exception hooks to
get the exceptions into the GUI. Steve tried to implement something
like this for GTK -- I can't remember what the final result was.
I think a good place to start would be to remove all instances of
error_msg* from the mpl front end and backend code, and then see where
we are. Any major problems with that?
JDH