matplotlib-devel Mailing List for matplotlib

What's new in matplotlib 0.74

basic unicode support in *Agg and PS

  See examples/unicode_demo.py.  Unicode strings are rendered in the
  agg and postscript backends.  Currently, all the symbols in the
  unicode string have to be in the active font file.  In later
  releases we'll try and support symbols from multiple ttf files in
  one string.  No support yet for unicode ttf filenames

Auto-legends

  The automatic placement of legends is now supported with loc='best';
  see examples/legend_auto.py.  We did this at the matplotlib sprint
  at pycon -- Thanks John Gill and Phil! Note that your legend will
  move if you interact with your data and you force data under the
  legend line.  If this is not what you want, use a designated
  location code.

Quiver (direction fields)

  Ludovic Aubry contributed a patch for the matlab compatible quiver
  method.  This makes a direction field with arrows.  See
  examples/quiver_demo.py

boxplot

  David Haas contributed a matlab-compatible boxplot function -- see
  examples/boxplot_demo.py.  This currently returns all the boxplot
  boxes, whiskers, flyer points, etc as a list of lines.  This will
  soon be refactored to return multiple lists so that the different
  elements can be more readily configured.

Hubble data example

  Perry Greenfield of STScIcontributed this nice example showing
  Hubble data with overlayed
  contours. http://matplotlib.sf.net/screenshots.html#hstdemo

minor enhancements and bug-fixes

  Some ticker locations bugs were fixed including a problem causing a
  memory error in psd, an ellipse bug in backend ps that was causing
  errant lines was fixed, svg text enhanced, added label kwarg to axes
  constructor to support creation of otherwise identical axes, fixed
  the NULL string pointer causing some Japanses fonts to segfault mpl

Downloads at http://matplotlib.sf.net

JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    JDH>  Here is my near term wish list for the PS backend:

    JDH> - implement draw_markers and draw_lines with the new API
    JDH> (transform is done in backend).  There are comments in
    JDH> backend_bases and in backend_ps to get you started

    Darren> I started looking into this tonight, but I am pretty much
    Darren> lost. The comments are a little too abstract for me right
    Darren> now, I cant find a footing. Could you offer some more
    Darren> details?

Sure, maybe more than you had bargained for <wink>.  I'm CC-ing the
dev list in case any of this information is useful to others. [BTW,
Darren is tentatively offering to take on some of the work to keep the
PS backend up to snuff]

There are several motivations to change backend renderer API, most of
them based on limitations or inefficiencies of the current API

  * The renderer interface is based on the GTK drawing model, which
    doesn't have a path concept, and is thus a bit behind most drawing
    APIs: ps, pdf, svg, cairo, agg, libart, etc...

  * Once you have a draw path method, many of the other methods
    (draw_rectangle, draw_polygon) become superfluous since they are
    just special cases of draw_path.  [ There is some debate about
    whether it is useful to keep these redundant methods around for
    efficiency or convenience.  ]

  * Many backends (svg, ps, agg) have transformation support built-in
    (at least for affine transformations).  I initially did the
    transformations in the front-end for convenience to backend
    writers (backends always work in display coords) but this caused
    several problems, inefficiency being one, and the new API moves
    the transformation to the backend.  Among other things, it allows
    the backend to fail gracefully when transforming on a per-element
    basis (log of non-positive data) w/o a mask or w/o an extra pass
    through the data.  For large numbers of points, the savings can be
    appreciable.  So the new backend methods are passed a
    Transformation instance.

  * We needed a draw_markers method.  draw_markers is a special case
    where the same path is repeatedly drawn at many places.  In the
    old API, we would do something like this for draw_plus in the
    Line2D class

            for (x,y) in zip(xt, yt):
                renderer.draw_line(gc, x-offset, y, x+offset, y)
                renderer.draw_line(gc, x, y-offset, x, y+offset)

    This is enormously inefficient, because of all the extra function
    calls and because of all the gc state setting that must be done on
    each call to draw_line in the inner loop.  In the new API, we do

            path = agg.path_storage()
            path.move_to(-offset, 0)
            path.line_to( offset, 0)
            path.move_to( 0, -offset)
            path.line_to( 0, offset)
            renderer.draw_markers(gc, path, None, xt, yt, self._transform)

    and the backend only has to set the gc state once.  Also, agg can
    cache the rasterized path and display it at many locations which
    is fast.

So those are the motivations.  There are three new methods that have
been introduced thus far.  The plan is introduce these three new
methods and then remove many of the redundant methods, so the overall
number of renderer methods will decrease.

  draw_markers - draw the same path at many locations
  draw_path    - draw an agg path (details later)
  draw_lines   - already exists but new method has trans in backend

The signatures of these three methods are 

  draw_markers(self, gc, path, rgbFace, x, y, trans):
  draw_path(self, gc, rgbFace, path, trans)
  draw_lines(self, gc, x, y, trans)

These should be documented in backend_bases, but gc is a backend
GraphicsContext, rgbFace is an rgbTuple or None, x and y are numerix
arrays, path is an agg.path_storage and trans is a
matplotlib.transforms.Transformation instance.  Details on these
latter two to follow.

path is an agg.path_storage instance.  In the first implementation of
draw_markers in backend_ps, path was simply a list of (code
vertices...) where code was one of STOP, MOVETO, LINETO, CURVE3,
CURVE4, ENDPOLY and vertices were a bunch of x,y verts.  I
subsequently decided to just use the agg path class for this (wrapped
by SWIG) because it is more generally useful (the code in backend_ps
_draw_markers is thus stale).  Here is a script that illustrates the
path_storage class from matplotlib.agg import path_storage

  p = path_storage()
  p.move_to(10,10)
  p.line_rel(100,100)
  p.line_rel(0,-100)
  p.line_to(30,30)
  p.curve3(20,30,40,50)

  for i in range(p.total_vertices()):
      cmd, x, y = p.vertex(i)
      print cmd, x, y

This script outputs

  peds-pc311:~/python/projects/matplotlib/unit> python path_storage.py
  1 10.0 10.0
  2 110.0 110.0
  2 110.0 10.0
  2 30.0 30.0
  3 20.0 30.0
  3 40.0 50.0

Note that there are more vertices than commands used to create the
path, because there are two vertices generated by the curve3 call.
The 1,2,3 command codes are from an agg ENUM, and are found in
agg22/include/agg_basics.h  

    enum path_commands_e
    {
        path_cmd_stop     = 0,        //----path_cmd_stop    
        path_cmd_move_to  = 1,        //----path_cmd_move_to 
        path_cmd_line_to  = 2,        //----path_cmd_line_to 
        path_cmd_curve3   = 3,        //----path_cmd_curve3  
        path_cmd_curve4   = 4,        //----path_cmd_curve4  
        path_cmd_end_poly = 6,        //----path_cmd_end_poly
        path_cmd_mask     = 0x0F      //----path_cmd_mask    
    };

See agg22/include/agg_basics.h, agg22/include/agg_path_storage.h and
swig/agg_path_storage.i for more information on available methods of
the agg path_storage class.   

You will need to translate these path primitives into the basic
postscript moveto, lineto, etc commands.  For the curve3 you would use
a cubic spline.  I don't know if postscript has a quartic spline...

The Transformation class is fairly well documented in transforms.py
and in the _draw_markers prototype method I wrote in backend_ps.  Here
is an example usage

        if trans.need_nonlinear():
            x,y = trans.nonlinear_only_numerix(x, y)

        # the a,b,c,d,tx,ty affine which transforms x and y
        vec6 = trans.as_vec6_val()

vec6 is a standard length 6 vector containing the information needed
to make an affine transformation.  Note the call to
transform.nonlinear_only_numerix(x, y) can fail (eg log of nonpositive
data).  I may provide some helper function in extension code to
support this.  What you want is a function that returns the
transformed data with a mask indicating the points to be skipped.  I
suggest you not worry about this right now -- if the transformation
fails because the user has illegal data that is OK for the time being.
It is easier in the agg extension code because I to the transformation
element-by-element in a c++ loop and drop points on which the
transformation fails.  This would probably be prohibitively slow in
python.

Note that I hid the _draw_markers prototype method in backend_ps with
a prefix underscore because it is incomplete and because I am using
the existence of that method in Line2D as a sentinel for whether a
backend as implemented the new API.  For example, in lines.py

  self._newstyle = hasattr(renderer, 'draw_markers')

So once you implement draw_markers, you need to implement draw_lines
with the new signature.  draw_path isn't utilized yet by the
front-end, but it will be nice to expose a path primitive for people
who want to make splines, etc.

I'll try and take this email and turn it into something more formal,
or use it to rewrite backend_bases and backend_template.  So far, the
only backend besides agg to be ported to the new API is cairo -- I
guess as long as the old API is still working there is little
incentive to do it.  I've been holding off *requiring* the new API
because it would irreparably break some backends that don't support
paths (gtk, wx, gd).  Some of these (gtk, wx) have been essential for
some people because they support unicode.  But now that agg and ps
support unicode, this is no longer so important.  We can also provide
a helper method that converts simple paths (those comprised of moveto,
lineto and endpoly) into draw_line and draw_polygon methods if we want
to keep these backends on board.  Also, Steve thinks GTK may be
getting paths in the near future as they move to a cairo renderer,
which suggests that waiting may be the right move.

OK, that should be enough to get you started.  Sorry for the
incomplete set of documentation or guidelines.  There has been a lot
of discussion on where the backends should be going, and since I've
been mulling all the options I've been slow to offer clear guidance in
the backend documentation.  I think your first objective should be to
figure out how to translate an agg.path_storage into a postscript
path -- the rest should be easy :-)

Let me know if you have any more questions!

JDH

Just wanted to let you know that I finished adding unicode support for
agg and postscript.  The changes are in CVS; see
examples/unicode_demo.py

I'm not a big consumer of unicode so this is lightly tested but it
does work with the western unicode strings and fontfile names I tested
on agg and ps.

In the process of getting text layout right in PS I discovered that
glyph.horiAdvance doesn't do what I thought, since it effectively
"snaps to pixel".  This was causing all kinds of layout badness in
postscript unicode (postscript doesn't support unicode, so you have to
layout the strings "by hand" character-by-character).  The trick was
to expose glyph.linearHoriAdvance which is the device independent
version; likewise I discovered that there were various kerning modes,
some of which are more appropriate for device independent layout.  I
think this error also underlies some of the current layout badness in
mathtext, which was also using glyph.horiAdvance.

I made a furtive attempt to add kerning to mathtext, but then
discovered that the cm truetype fonts do not have kerning information
in them at all. I took Robert Kern's (no pun intended) advice to get
the kerning information from the tfm files using tftopl, but these are
in "display device" coordinates so I am not sure how to properly use
it (multiply by an EM??).

But I'm kind of down on the Bakoma cm truetype fonts in any case,
because of their noncommercial license restrictions and because some
of the glyphs look terrible.  For example, check out the "t" in

  title(r'$\rm{this\ is\ a\ test}$')

Also there is the unresolved problem with how exactly the vertical
offset works in the cmex file, which neither Paul nor I were able to
figure out despite days of banging our heads against it.

Now that I cam getting my head around unicode, I'm considering a new
solution for mathtext, some of which we've touched on in previous
threads:

 * ship the umbelleck fonts with mpl (no license restrictions)

 * rebuild the data tables to map TeX names to unicode codes (I think
   Robert pointed out a link to an existing map, but it was GPLd and
   there was some discussion of whether we could rip out the tables).
   Right now, mathtext maps TeX symbols to (fontname, glyphindex)
   tuples, which is just plain dumb.  Hmm, it occurs to me suddenly
   that I can use the existing tables to build the unicode tables
   since I can use the font module to map glypindex -> unicode.

 * Rather than hardcode the font names with the symbol, query all the
   fontfiles on the system to see which unicode characters they
   provide.  Thus one could do simple mathtext (eg super/sub,
   equations) with the default font (eg Vera) of you were only using
   symbols provided by Vera.

 * Fix the basic layout problems -- some of this resulted from the
   glyph.horiAdvance problem, and some of it from not handling
   kerning, and some of it is still hard, eg cross font kerning.  If
   we modify text.py to support embedded mathtext, this would be less
   of an issue, particularly now that we have unicode.  Eg, you can
   use unicode text in the font of your choice to do accents and many
   special characters, and fall back on mathtext only for the
   super/sub scripting and other equation like stuff.

JDH

Charles Moad wrote:
> 	In learning matplotlib's backend API I played around in starting a
> Quartz image backend.  FWIW I am posting this if anyone wants to have a
> look.  I made a quick page on my wiki:
> 
> http://euclid.uits.iupui.edu/wiki/index.php/Matplotlib

The last time I looked at the Apple-provided wrappers, I found them to 
be inadequate for drawing stuff. If I remember correctly, some of the 
arguments require arrays of <Foo>, but they never wrote the typemaps to 
convert Python lists of <Foo> to the appropriate <FooPtr>. Worse, 
there's no source or documentation; you have to fly blind with the 
SWIGged API.

So I wrote ABCGI (A Better CoreGraphics Interface; I'm uncreative). It's 
part of Enthought's Kiva, but it could be trivially ripped out to stand 
alone.

http://svn.enthought.com/svn/enthought/branches/converge/kiva/mac/

It's more complete than the Apple wrappers, and plays nicely with 
Numeric. It would need some numerixifying to play nicely with 
matplotlib, probably. It plays nicely with PyObjC and PIL, too.

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> 	In learning matplotlib's backend API I played around
    Charles> in starting a Quartz image backend.  FWIW I am posting
    Charles> this if anyone wants to have a look.  I made a quick page
    Charles> on my wiki:

    Charles> http://euclid.uits.iupui.edu/wiki/index.php/Matplotlib

Hey Charles,

It was good to meet you at scipy -- thanks for putting this up.

    Charles> 	I am probably more interested in starting a PyObjC
    Charles> backend to provide interactive and agg options as well.
    Charles> Is this something that should wait for the backend
    Charles> refactoring???

I think you should proceed with this.  The GUI stuff is independent of
the backend rendering, so will work regardless.  You might take a look
at the gtk backend as a guide, which is the most modular in the sense
that you can reuse the gtk GUI components with Cairo, Agg or native
GDK rendering. Also, if you incorporate agg rendering, you'll be
insulated from any backend changes, since agg will handle the drawing.
Finally, if you want to use native rendering which I think you should
since you've already gotten a good start, it will be an easy port in
any case since most of the issues will be the same whichever final
backend API we settle on.

JDH

	In learning matplotlib's backend API I played around in starting a
Quartz image backend.  FWIW I am posting this if anyone wants to have a
look.  I made a quick page on my wiki:

http://euclid.uits.iupui.edu/wiki/index.php/Matplotlib

	I am probably more interested in starting a PyObjC backend to provide
interactive and agg options as well.  Is this something that should wait
for the backend refactoring???

- Charlie

Hi,

The attached patch fixes a few text-related issues in the SVG backend.
The first two were suggested by Bryan Cole on the list a month and a
half ago.

1. Don't emit a carriage return before and after the string inside the
<text> element. This was causing a problem in some SVG viewers.
2. Use font-family and font-style rather than the font-name used in
the PS backend. Now Inkscape gets the right font.
3. Don't define a stroke-width. This was making all text look bold.

Regards,

Jared

Hi,

I'm new to matplotlib and very impressed by the examples (the only thing
I've tried so far). Thanks!

While trying to generate the documentation with pydoc, I've found what
looks like a bug in lib/matplotlib/enthought/traits/ctraits.c: in
traits.py, one can read:

  class CTrait ( cTrait ):

where cTrait is a type created in ctraits.c. When pydoc visits
traits.py, its finds that CTrait.__bases__ is None:

Traceback (most recent call last):
  File "/usr/bin/pydoc", line 4, in ?
    pydoc.cli()
  File "/usr/lib/python2.4/pydoc.py", line 2235, in cli
    writedocs(arg)
  File "/usr/lib/python2.4/pydoc.py", line 1497, in writedocs
    writedocs(path, pkgpath + file + '.', done)
  File "/usr/lib/python2.4/pydoc.py", line 1497, in writedocs
    writedocs(path, pkgpath + file + '.', done)
  File "/usr/lib/python2.4/pydoc.py", line 1497, in writedocs
    writedocs(path, pkgpath + file + '.', done)
  File "/usr/lib/python2.4/pydoc.py", line 1507, in writedocs
    writedoc(modname)
  File "/usr/lib/python2.4/pydoc.py", line 1483, in writedoc
    page = html.page(describe(object), html.document(object, name))
  File "/usr/lib/python2.4/pydoc.py", line 295, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "/usr/lib/python2.4/pydoc.py", line 602, in docmodule
    for base in value.__bases__:
TypeError: iteration over non-sequence
~ %

or, with a bit more debugging information inserted in pydoc.py:

Flo-debug: key = 'StaticAnyTraitChangeNotifyWrapper'
Flo-debug: value = <class matplotlib.enthought.traits.trait_notifiers.StaticAnyTraitChangeNotifyWrapper at 0x40385b3c>
Flo-debug: value.__bases__ = ()
Flo-debug: key = 'StaticTraitChangeNotifyWrapper'
Flo-debug: value = <class matplotlib.enthought.traits.trait_notifiers.StaticTraitChangeNotifyWrapper at 0x40378a4c>
Flo-debug: value.__bases__ = ()
Flo-debug: key = 'TraitChangeNotifyWrapper'
Flo-debug: value = <class matplotlib.enthought.traits.trait_notifiers.TraitChangeNotifyWrapper at 0x403788fc>
Flo-debug: value.__bases__ = ()
wrote matplotlib.enthought.traits.trait_notifiers.html
Flo-debug: key = 'TraitArray'
Flo-debug: value = <class 'matplotlib.enthought.traits.trait_numeric.TraitArray'>
Flo-debug: value.__bases__ = (<class 'matplotlib.enthought.traits.trait_handlers.TraitHandler'>,)
wrote matplotlib.enthought.traits.trait_numeric.html
Flo-debug: key = 'CTrait'
Flo-debug: value = <class 'matplotlib.enthought.traits.traits.CTrait'>
Flo-debug: value.__bases__ = (<type 'cTrait'>,)
Flo-debug: key = 'Callable'
Flo-debug: value = <matplotlib.enthought.traits.traits.CTrait object at 0x403a2dec>
Flo-debug: value.__bases__ = None
Traceback (most recent call last):
  File "/usr/bin/pydoc", line 4, in ?
    pydoc.cli()
  File "/usr/lib/python2.4/pydoc.py", line 2239, in cli
    writedocs(arg)
  File "/usr/lib/python2.4/pydoc.py", line 1501, in writedocs
    writedocs(path, pkgpath + file + '.', done)
  File "/usr/lib/python2.4/pydoc.py", line 1501, in writedocs
    writedocs(path, pkgpath + file + '.', done)
  File "/usr/lib/python2.4/pydoc.py", line 1501, in writedocs
    writedocs(path, pkgpath + file + '.', done)
  File "/usr/lib/python2.4/pydoc.py", line 1511, in writedocs
    writedoc(modname)
  File "/usr/lib/python2.4/pydoc.py", line 1487, in writedoc
    page = html.page(describe(object), html.document(object, name))
  File "/usr/lib/python2.4/pydoc.py", line 295, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "/usr/lib/python2.4/pydoc.py", line 606, in docmodule
    for base in value.__bases__:
TypeError: iteration over non-sequence
~ %

You can see from the preceding debug information that classes such as
TraitChangeNotifyWrapper have their __bases__ attribute set to the empty
tuple, not to None. The Python documentation also says that __bases__
should be a tuple:

  __bases__
    The tuple of base classes of a class object. If there are no base
    classes, this will be an empty tuple.

therefore the None value we get for CTrait.__bases__ seems to be a bug
in traits (probably in ctraits.c), not one in pydoc.

All this with matplotlib 0.73.1 and:

  Python 2.4.1c2 (#2, Mar 19 2005, 01:04:19) 
  [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2

Thanks,

-- 
Florent

>>>>> "Matt" == Matt Newville <new...@ca...> writes:

    Matt> I hope my earlier email didn't sound too grumpy!

No, I think I was just over-stressed.  I was just frantically packing
for a week in DC at pycon, preparing for a cross-country road trip
with my wife and three kids, and wanted a stable release on the web
site for the pycon presentation.  I had to run to the office before we
left to do a win32 re-build to fix the win32 wx segfault, so maybe I
was a bit testy.

Pycon is fun -- met lots of good people.  Now I have to head off for
more talks.  

Thanks for all the hard work...

JDH

Brendan, 

> 2005-03-24 18:41:16.080 Python[2578] ***
> _NSAutoreleaseNoPool(): Object 0x6266bd0 of class NSCFString
> autoreleased with no pool in place - just leaking

Sorry, but I don't know what's causing this message.  I take it
this is still related to your earlier message:

> I"ve been tooling around with matplotlib, as graciously
> packaged by Chris Barker, and hosted on Bob Ippolito"s
> pythonmac.org/packages site.  Everything seems to be working
> smoothly, but I"ve run into a couple of warnings I can"t
> decrypt.
> 
> 1) Executing the following code,
> #! /usr/bin/pythonw
> import pylab
> pylab.plot([1, 2, 3], [4, 5, 6])
> pylab.show()
> 
>  <snip>

For what it's worth, I don't get any error messages from this
script, and the plot looks fine.  That's with Mac OS 10.3.8,
wxPython 2.5.4.1, matplotlib 0.73, and using rc={backend:WXAgg,
numerix:Numeric, interactive:False}.  I installed maplotlib from
source, so maybe the installer is causing this trouble???

Hope that helps,

--Matt Newville

On 23-Mar-05, at 11:26 PM, 
mat...@li... wrote:

> Even better, I don't get the leaking memory error
> when I dismiss the window

Crap, scratch that, yes I do:

2005-03-24 18:41:16.080 Python[2578] *** _NSAutoreleaseNoPool(): Object 
0x6266bd0 of class NSCFString autoreleased with no pool in place - just 
leaking

Anywhere I can log this bug?
   -Brendan

Hey cool.  I just installed wxPython 2.5.4.1 (was using 2.5.3.1 which I 
installed no more than a month ago),  and sure enough the toolbar 
buttons look great.  Even better, I don't get the leaking memory error 
when I dismiss the window.

-Brendan


>
> Hi John,
>
>>> wx is still broken on OS X (the toolbar icons look bad).
>>
>> Hmm, I use OS X regularly, but don't use the toolbars:  I'll
>> look into the bad icons.
>
> The toolbar icons for both toolbars look fine to me on OS X 10.3
> (matplotlib 0.73, wxPython 2.5.4.1, Apple's python2.3).  Perhaps
> this was fixed with wxPython 2.5.4.1 ???
>
> --Matt

Hi John,

> > wx is still broken on OS X (the toolbar icons look bad).
> 
> Hmm, I use OS X regularly, but don't use the toolbars:  I'll
> look into the bad icons. 

The toolbar icons for both toolbars look fine to me on OS X 10.3
(matplotlib 0.73, wxPython 2.5.4.1, Apple's python2.3).  Perhaps 
this was fixed with wxPython 2.5.4.1 ???

--Matt

Hi John,

> I totally agree with everything you said.  wxapp should not be
> instantiated at module level in backend_wx.  Unfortunately,
> doing it at show level breaks win32 pylab users -- in fact it
> segfaults with narry a helpful traceback to guide.  I think
> the current situation (wxapp at module level) is a bug and
> should be fixed.  I simply don't have the resources to do it
> myself.  Someone needs or do the dirty work of getting it
> organized in a way that works across platforms and idioms
> (pylab versus app development).  

I hope my earlier email didn't sound too grumpy!  

It does seem that it may be worth thinking about long-term
design and the API and layout of backends again. That's not to
say that the current design and layout is bad, but a better
separation of the library v. interactive code could be helpful.

Then again, maybe it's good enough as is, and it's only the wx
backend that needs work.  At this point, there's already enough
inertia of existing code, even subtle changes could have
significant consequences and shouldn't be done lightly.

> wx is still broken on OS X (the toolbar icons look bad).  I
> would be very thankful if you would help with this -- it's
> just that we have to make sure that fixing one thing doesn't
> break something else, and that changes need to be tested on
> win32, linux and OS X in applications and in pylab.  
> Admittedly, that is a lot of work: 3 operating systems and 2
> modes is 6 combinations.  But this is just one of 5 GUIs
> matplotlib supports, so I hope you can appreciate why I can't
> do it myself.

Hmm, I use OS X regularly, but don't use the toolbars:  I'll
look into the bad icons.  Personally, I don't much care for the
toolbars and don't use 'from matplotlib.pylab import *'.  That
probably means I'm not looking at many use cases.

For GUIs and libraries where the result is visual, defining a
testing procedure seems difficult.  Can you (anyone?) suggest a
suite of "standard tests" that might be partially automated?

--Matt

> I just upgraded mpl to the most recent CXX and I still get the segfault. 
> What would be most useful is if you created a minimal CXX extension
> independent of mpl and see if you can replicate the bug.  If so, could you
> file a bug report on the CXX sf project page?

I stripped the _transforms.cpp module out of MPL and built it
separately using the latest PyCXX. The resulting module doesn't show the
presvious seg-fault problem. I.e. 

>>> import _transforms
>>> V=_transforms.Value(0)
>>> V
<BinOp object at 0x9ee8fac>
>>> type(V)
<type 'BinOp'>
>>> type(V).__bases__
(<type 'object'>,)
>>>

This code generates a seg-fault using matplotlib._transforms. Note, I
also removed all the _nc_transforms() and _na_transforms() stuff.

To build _transforms separately, I needed to make a init_transforms()
C-function. The MPL code only initialises _nc_transforms() (I don't have
Numarray installed).

Whats the relationship between _transforms.cpp and _nc_transforms.cpp ?
They seem to define the same stuff. I can't see where the _transforms
module itself is initialised in the MPL code.

Bryan


> 
> 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

>>>>> "Matt" == Matt Newville <new...@ca...> writes:

    >> From my point of view, the decisions and consequences of
    Matt> interactivity should not be in backend_*, but in the code
    Matt> exposing the interactivity.  If pylab needs to
    Matt> auto-magically create a wxPySimpleApp, do it in pylab where
    Matt> it won't bother anyone else.

I totally agree with everything you said.  wxapp should not be
instantiated at module level in backend_wx.  Unfortunately, doing it
at show level breaks win32 pylab users -- in fact it segfaults with
narry a helpful traceback to guide.  I think the current situation
(wxapp at module level) is a bug and should be fixed.  I simply don't
have the resources to do it myself.  Someone needs or do the dirty
work of getting it organized in a way that works across platforms and
idioms (pylab versus app development).  wx is still broken on OS X
(the toolbar icons look bad).  I would be very thankful if you would
help with this -- it's just that we have to make sure that fixing one
thing doesn't break something else, and that changes need to be tested
on win32, linux and OS X in applications and in pylab.  Admittedly,
that is a lot of work: 3 operating systems and 2 modes is 6
combinations.  But this is just one of 5 GUIs matplotlib supports, so
I hope you can appreciate why I can't do it myself.

Thanks!
JDH

Hi John,

>  On
>     TISCALI> stdout, an error appears with WXAgg or WX backends:

> This arises from a subtle, platform dependent problem with
> where the wx backend instantiates a wxapp.  Matt, I've
> reverted the wxapp instantiation to the old place.  I agree
> there is no logical reason why it needs to be where it is, but
> as I indicated before, I ran into troubles trying to do it the
> logical way.  This is the trouble I was referring to, but
> couldn't remember exactly what it was.
 
Hmm, OK, I guess.  I think this could cause more problems like
Marcin W. saw.  Then again, I was never able to reproduce these
problems, so I'm not sure how likely they are to crop up again.

I think there is a mismatch between developing libraries for
writing applications and trying to support
   from matplotlib.pylab import *

for multiple backends and platforms and expect everything to
auto-magically "Just Work" with suitably vague definitions of
Just and Work to make people think this is what they want.

So now we're back to a situation where having
   from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg

**creates** a wx.PySimpleApp?? Ick. To use a PySimpleApp, one
can either create a new one:
   import wx
   app = wx.PySimpleApp()

or access the one already squirreled away:
   app = matplotlib.backends.backend_wx.wxapp

Of course, no one does the latter because no one would expect
that importing a FigureCanvasWxAgg would have created a
wx.PySimpleApp.

From my point of view, the decisions and consequences of
interactivity should not be in backend_*, but in the code
exposing the interactivity.  If pylab needs to auto-magically
create a wxPySimpleApp, do it in pylab where it won't bother
anyone else.

Thanks!  

--Matt

>>>>> "TISCALI" == TISCALI  <phi...@ti...> writes:

    TISCALI>  some problems:
 
 from matplotlib.matlab import *
    TISCALI> doesn't work in the samples (see examples-0 73.zip)

    TISCALI> from matplotlib.pylab import * works well.
 
 On
    TISCALI> stdout, an error appears with WXAgg or WX backends:
 


This arises from a subtle, platform dependent problem with where the
wx backend instantiates a wxapp.  Matt, I've reverted the wxapp
instantiation to the old place.  I agree there is no logical reason
why it needs to be where it is, but as I indicated before, I ran into
troubles trying to do it the logical way.  This is the trouble I was
referring to, but couldn't remember exactly what it was.

Because I'm leaving town today and want something stable for pycon, I
went ahead and rolled out a quick bug-fix release 0.73.1 with these
changes (and Fernando, you number patch got to slip in!).

To everyone who contributes code to mpl, particularly GUI code, please
test on win32 if it is at all possible.  win32 downloads account for
half of all mpl downloads, and the GUIs are not exactly the same
across platforms.

Thanks,
JDH

On Fri, 2005-03-18 at 20:17 -0800, matplotlib-devel-
re...@li... wrote:
> On Fri, 2005-03-18 at 20:17 -0800, matplotlib-devel-
> re...@li... wrote:
> > >>>>> "John" == John Hunter <jdh...@ac...> writes:
> > 
> >     John> Just trying to build 0.73 on win32 and hot a snag on the new
> >     John> _backend_gdk.  My GTK win32 install, admittedly a bit out of
> >     John> date, does not have
> > 
> >     John>   #include <gdk/gdkx.h>
> > 
> > Hmm...
> > 
> > I used the time honored "comment it out and see what happens" and was
> > able to compile and run GTK and GTKAgg examples on win32.  As I
> > understand it, gdkx is an X specific extension anyway.
> > 
> > Are there problems with this approach?
> > 
> > JDH
No, it looks good, I've removed the gdkx.h line from cvs too.
When writing the extension I copied some of the code from a cairo gtk
extension which is X11 specific. But luckily the _backend_gdk function
pixbuf_get_pixels_array() is not X11 specific, so the gdkx.h include is
not even needed. Thanks for tracking it down.

Steve

What's new in matplotlib 0.73

new contour functionality

  Filled contours (polygons) with contourf and clabel . See
  examples/contour_demo.py, examples/contourf_demo.py,
  examples/contour_image.py and the screenshot at
  http://matplotlib.sf.net/screenshots.html#pcolor_demo. Thanks Nadia
  and Eric for lots of hard work. This code is not perfect, so please
  let us know if you find bugs or problems.

native font support back in PS

  Added new rc param param ps.useafm so ps backend can use native
  fonts; this currently breaks PS mathtext but makes for smaller files

colorbar now a figure method

  Refactored colorbar code out of pylab into Figure API for API
  developers. matplotlib.pylab colorbar is now a thin wrapper to this
  function.

minor enhancements and bug-fixes

  Experimental support for GTK w/o double buffering, added double
  buffering to gtkagg, exposed some core agg functionality in
  matplotlib.agg, upgraded wrapper generator to CXX 5.3.1, added a
  custom pixel transfer function for GTK which works for Numeric and
  numarray, added patch for problem with Japanse fonts in windows
  registry, fixed ticks for horizontal colorbars, fixed labelsep
  legend bug

Downloads at http://matplotlib.sf.net

JDH

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> Just trying to build 0.73 on win32 and hot a snag on the new
    John> _backend_gdk.  My GTK win32 install, admittedly a bit out of
    John> date, does not have

    John>   #include <gdk/gdkx.h>

Hmm...

I used the time honored "comment it out and see what happens" and was
able to compile and run GTK and GTKAgg examples on win32.  As I
understand it, gdkx is an X specific extension anyway.

Are there problems with this approach?

JDH

Just a reminder that there will be a matplotlib sprint on Monday the
21st before PyCon.  If you are in the DC area and what to hack on
matplotlib, please come out!

  http://www.python.org/moin/MatplotlibSprint

Hope to see you there!
JDH

Just trying to build 0.73 on win32 and hot a snag on the new
_backend_gdk.  My GTK win32 install, admittedly a bit out of date,
does not have

  #include <gdk/gdkx.h>

I'm using GTK-Development-Environment-2.2.4.1.exe and
GTK-Runtime-Environment-2.2.4.1.exe which I got a while ago from
http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=71737

Any ideas on how to best proceed? 

JDH
 

On Thu, 2005-03-17 at 17:16 -0600, John Hunter wrote:
> ### Cairo CVS build error
> make[2]: Entering directory `/home/jdhunter/python/cvs/cairo/src'
> if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/X11R6/include    -I/usr/local/include/libpng12      -I/usr/local/include   -I/usr/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes  -Wmissing-prototypes -Wmissing-declarations     -Wnested-externs -fno-strict-aliasing    -g -O2 -MT cairo.lo -MD -MP -MF ".deps/cairo.Tpo" -c -o cairo.lo cairo.c; \
> then mv -f ".deps/cairo.Tpo" ".deps/cairo.Plo"; else rm -f ".deps/cairo.Tpo"; exit 1; fi
> mkdir .libs
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I/usr/X11R6/include -I/usr/local/include/libpng12 -I/usr/local/include -I/usr/include/freetype2 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -g -O2 -MT cairo.lo -MD -MP -MF .deps/cairo.Tpo -c cairo.c  -fPIC -DPIC -o .libs/cairo.lo
> In file included from cairo.h:48,
>                  from cairoint.h:60,
>                  from cairo.c:37:
> cairo-features.h:42:9: macro names must be identifiers
> cairo-features.h:48:9: macro names must be identifiers
> cairo-features.h:52:9: macro names must be identifiers
> cairo-features.h:56:9: macro names must be identifiers
> cairo-features.h:58:9: macro names must be identifiers
> cairo-features.h:60:9: macro names must be identifiers
> make[2]: *** [cairo.lo] Error 1

Here's some notes I found regarding changes to cairo-features.h:

1) The public header files will no longer be directly installed into
   the system include directory. They will now be installed in a
   subdirectory named "cairo", (eg. in /usr/include/cairo rather than
   in /usr/include).

   For applications using pkg-config, the change should be mostly
   transparent, as pkg-config will find the new directory.

   However, user will also need to manually remove the old versions of
   cairo.h and cairo-features.h from the system include directories in
   order to prevent them being found first.

Steve

On Thu, 2005-03-17 at 17:16 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> This looks incomplete, what's the Exception type?  I tried
>     Steve> on my system and it ran OK.
> 
> 
> Oops, the complete traceback is below.  Maybe my cairo is out of
> whack. Are you using CVS?
Yes, I'm using CVS. Cairo is currently undergoing rapid development so
one day CVS may compile, the next day it may not, and the day after it
may be fixed and working again. PyCairo will be constantly lagging
behind, trying to keep up with all the changes. Periodically cairo does
a snapshot release and I intend to do a pycairo snapshot release that is
synchronised to cairo snapshot.
The most recent releases are the cairo 0.4.0 and pycairo 0.4.0 snapshots
which should compile OK and work together.

> ### Cairo backend traceback
> peds-pc311:~/python/projects/matplotlib/examples> python simple_plot.py -dCairo
> Traceback (most recent call last):
>   File "simple_plot.py", line 15, in ?
>     savefig('simple_plot')
>   File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 712, in savefig
>     return fig.savefig(*args, **kwargs)
>   File "/usr/local/lib/python2.3/site-packages/matplotlib/figure.py", line 457, in savefig
>     self.canvas.print_figure(*args, **kwargs)
>   File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 647, in print_figure
>     orientation)
>   File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 561, in print_figure_fn
>     if ext == 'png': _save_png (figure, fileObject)
>   File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_cairo.py", line 583, in _save_png
>     ctx.set_target_png (fileObject, cairo.FORMAT_ARGB32, width, height)
> TypeError: Context.set_target_png() argument 1 must be string, not file
> peds-pc311:~/python/projects/matplotlib/examples>
This looks like an old pycairo version which took a filename (str) instead of a fileobject for set_target_png()

Steve