Thanks for the replies - since it worked Ok for other people I looked a bit further:
matplotlib 0.87.2, OS X 10.3.9, Numeric - 23.7, ipython 0.6.15
running quadmesh_demo.py in examples gives a bus error when the figure is rendered.
It turns out that the collections object returned by the line 16 of quadmesh_demo.py:
returns vertices with complex values i.e.
b = ax.pcolormesh(Qx,Qz,Z)
Out: [ 1.10000002+0.j,-1.99498999+0.j,]
this happens right away in pcolormesh since _coordinates are set there.
If I force a type cast as in:
b._coodinates = b._coodinates.astype(Numeric.Float32)
all goes well
I suspected that something was screwy in lines of pcolormesh (lines 2422 - 2326) in axes.py:
coords = zeros(((Nx * Ny), 2),"Float32")
# Numeric and numpy refuse to cast the Float64 arrays
# to Float32 with simple assignment, so we do it explicitly.
coords[:, 0] = X.astype(Float32)
coords[:, 1] = Y.astype(Float32)
it appears to be OK for a Float32 BUT if there is a string representation "Float32'" the Numeric module takes only the first character in this case an 'F' which implies complex for Numeric.
all appears OK for numarray and numpy.