matplotlib-users Mailing List for matplotlib

> 
> On Wed, 07 Sep 2005, Eric Firing apparently wrote: 
> 
>>> So, the big question is: is it OK, or at least potentially 
>>> OK, to change the pylab API for contour and contourf so 
>>> that they return a single object instead of a tuple? 
> 
> 
> This breaks the matlab analogy.
> I do not care about that myself,
> but people coming from matlab might.
> Maybe the right way to go is to provide an extended 
> contourgroup object 
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/contourgroupproperties.html
> and treat contour and contourf as convenience functions that 
> continue to work as they do.
> 
> fwiw,
> Alan Isaac

Alan,

Actually, it shouldn't hurt people coming from matlab, for two reasons:
1) the present mpl contour and contourf don't return the same things 
that the matlab versions do, anyway;
2) Mathworks has already broken their users' matlab code by changing the 
contour/contourf return values between version 6 and version 7.

The contourgroup is new in version 7.  What I have in mind is similar to 
it--although until your message, I had completely forgotten that this is 
the thing that broke all my matlab contouring in version 7.  So, the 
proposed change will make mpl contour less like matlab version 6 contour 
and more like version 7; but this is coincidental, not deliberate.

Eric

On Thursday 08 September 2005 23:55, Jeff Whitaker wrote:
> Nicolas:  Sounds like you need to set numerix='numarray'.  Try this at
> the beginning of your script:
>
> from matplotlib import rcParams
> rcParams['numerix']= 'numarray'
>
> -Jeff

Jeff : a huge thanks for your damn fast answer ! I was so desperate that I had 
fired up IDL, which I hadn't done for months ! I'm so glad to be able to 
stick with matplotlib !

cheers,
Nicolas

On 9/8/05, Mark Bakker <ma...@gm...> wrote:
>  I left the axis('scaled') option in, mostly as a novelty, and because I
> like it. But it is only useful if you don't have subplots. Maybe we shoul=
d
> just get rid of it, as it is not really needed anymore. I have no idea wh=
at
> 'scaled' and 'equal' do together.=20

please keep it - as it works now axis('scaled') is similar to the
matlab 'axis image' command, which is very useful. as explained in
matlab:

   AXIS EQUAL  sets the aspect ratio so that equal tick mark
       increments on the x-,y- and z-axis are equal in size. This
       makes SPHERE(25) look like a sphere, instead of an ellipsoid.
    AXIS IMAGE  is the same as AXIS EQUAL except that the plot
       box fits tightly around the data.

axis image is what you want if you like the grid axes to fit tightly
around an image. when the figure window is resized you want the aspect
ratio and the axis ranges preserved. when zooming in/out you want the
aspect ratio preserved.

Helge

Nicolas Girard wrote:

>Hi all,
>I need to use contour with data for x,y and z coordinates. My data is 
>contained in 3 numarray arrays called xi,z and rho.
>
>I can call contour with either of these 3 arrays without any problem. But when 
>it comes to pass the 3 arrays, here's the error I get:
>
>In [19]:contour(xi,z,rho)
>---------------------------------------------------------------------------
>exceptions.TypeError                                 Traceback (most recent 
>call last)
>
>/home/ngirard/.python/<console>
>
>/usr/lib/python2.4/site-packages/matplotlib/pylab.py in contour(*args, 
>**kwargs)
>   1784         hold(h)
>   1785     try:
>-> 1786         ret =  gca().contour(*args, **kwargs)
>   1787         draw_if_interactive()
>   1788     except:
>
>/usr/lib/python2.4/site-packages/matplotlib/axes.py in contour(self, *args, 
>**kwargs)
>   1251
>   1252     def contour(self, *args, **kwargs):
>-> 1253         return self._contourHelper.contour(*args, **kwargs)
>   1254     contour.__doc__ = ContourSupport.contour.__doc__
>   1255
>
>/usr/lib/python2.4/site-packages/matplotlib/contour.py in contour(self, *args, 
>**kwargs)
>    675             tlinewidths = [(w,) for w in linewidths]
>    676
>--> 677         C = _contour.Cntr(x, y, z.filled(), z.mask())
>    678         for level, color, width in zip(lev, tcolors, tlinewidths):
>    679             nlist = C.trace(level, points = 1)
>
>TypeError: Arguments x, y, z, (optional) mask  must be arrays.
>
>
>
>
>I really don't understand where the problem is. All arrays are of the same 
>nature:
>
>In [20]:for a in [xi,z,rho]:
>   .20.:  shape(a)
>   .20.:  type(a)
>   .20.:
>Out[20]:(1025, 1024)
>Out[20]:<class 'numarray.numarraycore.NumArray'>
>Out[20]:(1025, 1024)
>Out[20]:<class 'numarray.numarraycore.NumArray'>
>Out[20]:(1025, 1024)
>Out[20]:<class 'numarray.numarraycore.NumArray'>
>
>
>
>Do you have any idea to help me solve this problem ?
>
>Thanks in advance,
>cheers,
>Nicolas
>
>
>
>  
>

Nicolas:  Sounds like you need to set numerix='numarray'.  Try this at 
the beginning of your script:

from matplotlib import rcParams
rcParams['numerix']= 'numarray'

-Jeff


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

The axis('scaled') was a first quick-and-dirty implementation of getting th=
e=20
scale of a figure the same along both axes. When it was implemented in the=
=20
previous version, John Hunter commented (correctly) that it didn't work for=
=20
subplots. That is what triggered the clean implementation of axis('equal').=
=20
I think axis('equal') works correctly. Except for the known problem that th=
e=20
back button on the toolbar doesn't restore the previous position. I will tr=
y=20
to fix this in the next week or so.

I left the axis('scaled') option in, mostly as a novelty, and because I lik=
e=20
it. But it is only useful if you don't have subplots. Maybe we should just=
=20
get rid of it, as it is not really needed anymore. I have no idea what=20
'scaled' and 'equal' do together.=20

Regarding the autoscale_on attribute. I don't know what that was designed t=
o=20
do. Can anybody explain?

To summarize:
1. I will add the position to the history so that the backbutton works.
2. Let's remove the axis('scaled') option
3. I don't know how to keep axes scaled when the window size is changed.=20
Anybody know how to catch such an event?

Mark

On 9/8/05, Martin Richter <law...@gm...> wrote:
>=20
> Hello Mark,
> Hello everyone,
>=20
> I wrote myself a little program which juggled five commands in all=20
> possible
> orders saving each plottingresult in a png. What I could see was that=20
> (with
> autoscale_on=3DFalse) the commands
>=20
> imshow(something),
> plot(something)
> axis('scaled')
> axis('equal')
> axis([-2,2,-3,3]))
>=20
> had to obey two rules. Then and only then the plot looked like I wanted
> (i.e. it had the correct limits given by axis([...]) and a circle looked
> like a circle).
> (i) plot() has to be before axis([-2,2,-3,3])
> (ii) imshow() has to be before axis([-2,2,-3,3])
>=20
> I think (i) everyone knows from everyday experience with MPL. Then (ii)
> doesn't suprise too much.
>=20
> Remark 1)
> I put axis('equal') AND axis('scaled') in, just to check out
> if everything works fine. It seems to me that axis('scaled') overrules
> axis('equal').
> In other words: I suppose axis('equal') doesn' set fixLimits=3DFalse.
> I - preferring axis('scaled') - doesn't find this to bad. But nevertheles=
s
> it could be confusing to the user who prefers the other option ... on the
> other hand: Propably no-one uses axis('equal') AND axis('scaled') in one
> program (except me doing a 120 permutations ;-)
>=20
> Remark 2)
> Still: I can't become a really friend of this. If autoscale_on=3DTrue I=
=20
> would
> understand (i) and (ii). But it is False. When plotting doesn't autoscale
> why are the limits changed? In other words: Why (i) and (ii)? You could
> propably say: We already talked about the difference in
> axis('equal')
> axis([-2,2,-3,3])
> and
> axis([-2,2,-3,3])
> axis('equal').
> But this is not true for axis('scaled'). Here the order doesn't play a=20
> role
> (At least I saw this in a seperate example and I also couldn't figure out
> that the order played a role for 'scaled' in my permutations - notice the
> "Then and only then" before (i) and (ii)!)
>=20
> That's as far as I came right now.
> Bye,
> Martin
>=20
> PS: I don't know if this permutation-doing program is of any use to you.
> That's why I haven't attached it. If you would like to have it - let me=
=20
> know
> ... but I wouldn't exhibit it in the Louvre if you know what I mean ;-)
>=20
> --
> Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
> Satte Provisionen f=FCr GMX Partner: http://www.gmx.net/de/go/partner
>

Anybody know how to update the Matplotlib distribution contained within
the Enthought Python distribution?
There seems to be no uninstaller for any of the packages and I'd like to
update to the latest mpl.

thanks,
Travis
-- 
  Travis Brady
  td...@fa...

-- 
http://www.fastmail.fm - mmm... Fastmail...

Hi all,
I need to use contour with data for x,y and z coordinates. My data is 
contained in 3 numarray arrays called xi,z and rho.

I can call contour with either of these 3 arrays without any problem. But when 
it comes to pass the 3 arrays, here's the error I get:

In [19]:contour(xi,z,rho)
---------------------------------------------------------------------------
exceptions.TypeError                                 Traceback (most recent 
call last)

/home/ngirard/.python/<console>

/usr/lib/python2.4/site-packages/matplotlib/pylab.py in contour(*args, 
**kwargs)
   1784         hold(h)
   1785     try:
-> 1786         ret =  gca().contour(*args, **kwargs)
   1787         draw_if_interactive()
   1788     except:

/usr/lib/python2.4/site-packages/matplotlib/axes.py in contour(self, *args, 
**kwargs)
   1251
   1252     def contour(self, *args, **kwargs):
-> 1253         return self._contourHelper.contour(*args, **kwargs)
   1254     contour.__doc__ = ContourSupport.contour.__doc__
   1255

/usr/lib/python2.4/site-packages/matplotlib/contour.py in contour(self, *args, 
**kwargs)
    675             tlinewidths = [(w,) for w in linewidths]
    676
--> 677         C = _contour.Cntr(x, y, z.filled(), z.mask())
    678         for level, color, width in zip(lev, tcolors, tlinewidths):
    679             nlist = C.trace(level, points = 1)

TypeError: Arguments x, y, z, (optional) mask  must be arrays.




I really don't understand where the problem is. All arrays are of the same 
nature:

In [20]:for a in [xi,z,rho]:
   .20.:  shape(a)
   .20.:  type(a)
   .20.:
Out[20]:(1025, 1024)
Out[20]:<class 'numarray.numarraycore.NumArray'>
Out[20]:(1025, 1024)
Out[20]:<class 'numarray.numarraycore.NumArray'>
Out[20]:(1025, 1024)
Out[20]:<class 'numarray.numarraycore.NumArray'>



Do you have any idea to help me solve this problem ?

Thanks in advance,
cheers,
Nicolas

Message> For importing External Method in Zope, what is the module to=20
import?

Create a file (e.g. mpl.py) in INSTANCEHOME\Extensions.

------ mpl.py: ---------------------
from pylab import *
from os import *
from StringIO import StringIO
from PIL import Image as PILImage
from matplotlib.backends.backend_agg import FigureCanvasAgg

def chart(self):
    clf()
    dpi=3D72
    width=3D400
    height=3D300
    fig=3Dfigure(dpi, figsize=3D(width/dpi, height/dpi))
    #ax=3Dsubplot(111)
    x=3Darange(0, 2*pi+0.1, 0.1)
    sine=3Dplot(x, sin(x))
    legend(sine, "y=3Dsin x", "upper right")
    xlabel('x')
    ylabel('y=3Dsin x')
    grid(True)
    canvas =3D FigureCanvasAgg(fig)
    canvas.draw()
    size =3D canvas.get_width_height()
    buf=3Dcanvas.tostring_rgb()
    im=3DPILImage.fromstring('RGB', size, buf, 'raw', 'RGB', 0, 1)
    imgdata=3DStringIO()
    im.save(imgdata, 'PNG')
    self.REQUEST.RESPONSE.setHeader('Pragma', 'no-cache')
    self.REQUEST.RESPONSE.setHeader('Content-Type', 'image/png')
    return imgdata.getvalue()

-------------------------------------------

Then create an external method in ZMI (e.g. Id -> mplchart, module name =
->=20
mpl, function name -> chart).

> matplotlib or pylab  Do you also have to import numeric python first?

If you import pylab, then there is no need to import Numeric.

> I need a real world example not a 'foo.py' module.

See above.

Regards,
Sascha=20

On 9/8/05, Martin Richter <law...@gm...> wrote:

> Remark 2)
> Still: I can't become a really friend of this. If autoscale_on=3DTrue I w=
ould
> understand (i) and (ii). But it is False. When plotting doesn't autoscale
> why are the limits changed? In other words: Why (i) and (ii)? You could
> propably say: We already talked about the difference in


Hello,
I agree that autoscaling combined with e.g. axis('scaled') is really broken=
...=20

my worst annoyance is how the figure size is changed when I do
axis('scaled') and use the zoom to rect mode, e.g.

from pylab import *
im=3D3 ; jm=3D4
[y,x] =3D meshgrid(arange(0.5,jm+0.5), arange(0.5,im+0.5))
h =3D sqrt(x**2 + y**2)
pcolor(x,y,h)
axis([0,im,0,jm])
axis('scaled')
hsv()=20
show()
=20
then zoom to rect and pick a very "wide" rectangle - figure changes
size, now zooming to a tall rectangle  will make the figure size thin
and tall instead. clicking home restores the axis limits, but the
weird figure size remains... (I use cvs matplotlib)

humble suggestion for developers: using the right button to zoom out
to a rectangle is not intuitive - I would much prefer if a single
right click in the figure in this mode just took me back to the
previous axis limits.  and if axis('scaled') is on, it should preserve
the figure aspect ratio no matter what happen - window resize, zooming
in/out, whatever...

otherwise, matplotlib is really improving! good job. the only features
I miss are a pcolor and quiver capable of doing 500x500 data as fast
as pygist :)

for those hacking on the colorbar: the scipy xplt colorbar is nice. it
may be possible to use some of the scaling algs. from that one. (see
http://www.scipy.org/cvs/viewcvs/map?rmurl=3Dhttp%3A//scipy.net/cgi-bin/vie=
wcvsx.cgi/scipy1/xplt/colorbar.py%3Frev%3D1.7%26content-type%3Dtext/vnd.vie=
wcvs-markup)

sincerely,
Helge

I am a new Zope user and am trying to use matplotlib in a Zope application
and need some guidance on how to do so.  
 
From a previous post in February 2005 (2-17-05), someone had a similar
problem.  From the archives, I'm not quite sure it was solved.
This is the only related answer I found.
 
From: Yves Moisan <ymoisan@gr...>
  <http://images.sourceforge.net/images/msg.gif> Matplotlib in a Zope and
postgreSQL context   
2005-04-29 09:16	

  

 1) Is there a way people know of integrating Matplotlib into Zope ?  I had
to

 fight with the registry (yes, a windows box for now) to get matplotlib to

 install on the right Python (Zope"s, not the system Python) but more
importantly

 I am using an external method to gain access to matplotlib via Zope.  It
works,

 but it"s clumsy and I suspect loading up pylab could be quicker if I could
use

 Scripts (Python) objects in Zope.

For importing External Method in Zope, what is the module to import?
matplotlib or pylab  Do you also have to import numeric python first?  

What would the functions be in the External Method import?  (example: plot,
arange, xlabel, etc.???)

The other method listed was to install in the right Python (Zope's) by
fighting with the windows registry. How is this actually done from someone
with less computer programming knowledge?  Is matplotlib installed in the
python directory of the main Zope directory or the Zope Instance directory?
I copied the matplotlib directory from my python directory (not Zope) to
both the Zope directory (...\lib\python\) and Zope Instance directory
(...\Extensions\) in the hope one would work.

Error Type: ImportError
Error Value: import of "pylab" is unauthorized

How do I get security clearance for matplotlib?  The information from Zope
isn't as detailed as I would need.  I need a real world example not a
'foo.py' module.

Thank you.

Dave

On Sep 8, 2005, at 8:46 AM, John Hunter wrote:
> Kevin, Do you think it would be possible to make the BUILD_WXAGG logic
> a little smarter so that it doesn't kill the build process?  Or
> perhaps set BUILD_WXAGG to False by default.


I will review buildext.py and see if I can add a check for the presence 
of `wxPython.h'.  For now, you should probably set BUILD_WXAGG to False 
by default.

Maybe I should get this Kevin guy to help  ;-)

> I'm afraid this one will bite a lot of people who have wxpython 
> installed
> but not the devel headers (as noted in previous discussions, the 
> debian devel
> packages appear broken with respect to wxPython.h).

I'm working with Ron Lee to get that fixed.  It looks like it may be an 
upstream issue, in that the wxPython distutils script doesn't even try 
to install the headers.  It probably won't be a hard fix, once I've 
made sure I understand the problem.

Ken

On Wed, 07 Sep 2005, Eric Firing apparently wrote: 
> So, the big question is: is it OK, or at least potentially 
> OK, to change the pylab API for contour and contourf so 
> that they return a single object instead of a tuple? 

This breaks the matlab analogy.
I do not care about that myself,
but people coming from matlab might.
Maybe the right way to go is to provide an extended 
contourgroup object 
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/contourgroupproperties.html
and treat contour and contourf as convenience functions that 
continue to work as they do.

fwiw,
Alan Isaac

>>>>> "Noel" == Noel O'Boyle <no...@ca...> writes:

    Noel> (1) If I don't compile GTK, please don't make it the
    Noel> default. 

Yes, this is a common annoyance that needs to be fixed.  

    Noel> (3) If I need to edit matplotlibrc, please include the list
    Noel> of possible options beside each of the relevant lines. I had
    Noel> to look up the correct spelling for TkAgg in the source (the
    Noel> User Guide variously refers to tkagg, Tkagg, TkAgg) - there
    Noel> is an easier way.

In general we do

    numerix      : Numeric    # Numeric or numarray
    interactive  : False      # see http://matplotlib.sourceforge.net/interactive.html
    toolbar      : toolbar2   # None | classic | toolbar2
    timezone     : UTC        # a pytz timezone string, eg US/Central or Europe/Paris

...and see below...


    Noel> I appreciate all of the hard work by the matplotlib team and
    Noel> hope that my comments are helpful,

They are certainly helpful and we'll fix these as we can.  As you'll
notice from the volume of the mailing lists and the number of
different things matplotlib is trying to do, we have our hands pretty
full, so I encourage people to chip in wherever possible.  Eg, if
there is a specific rc line that could be better like

# the default backend; one of GTK GTKAgg GTKCairo FltkAgg QtAgg TkAgg 
# Agg Cairo GD GDK Paint PS SVG Template
backend      : GTKAgg     

and you can submit this fix instead, that will be most helpful.

If there is a bug in the manual (tkagg, TkAgg, TKAgg), if you could
download the source, edit it and submit the fixes, that would also be
helpful.

  http://cvs.sourceforge.net/viewcvs.py/matplotlib/users_guide

I realize that as a new user you often don't know where to find these
things or this information, but I just want to point it out now
because I encourage everyone to contribute what they can.

Thanks,
JDH

>>>>> "Nils" == Nils Wagner <nw...@me...> writes:

    Nils> Hi all, I am trying to build matplotlib from cvs on SuSE
    Nils> 9.1.

    Nils> python setup.py build results in

    Nils> src/_wxagg.cpp:55:34: wx/wxPython/wxPython.h: No such file
    Nils> or directory src/_wxagg.cpp: In member function `Py::Object
    Nils> _wxagg_module::convert_agg_to_wx_image(const Py::Tuple&)':
    Nils> src/_wxagg.cpp:105: error: `wxPyConstructObject' undeclared
    Nils> (first use this function) src/_wxagg.cpp:105: error: (Each
    Nils> undeclared identifier is reported only once for each
    Nils> function it appears in.)  src/_wxagg.cpp: In member function
    Nils> `Py::Object _wxagg_module::convert_agg_to_wx_bitmap(const
    Nils> Py::Tuple&)': src/_wxagg.cpp:129: error:
    Nils> `wxPyConstructObject' undeclared (first use this function)
    Nils> src/_wxagg.cpp: In function `void init_wxagg()':
    Nils> src/_wxagg.cpp:260: error: `wxPyCoreAPI_IMPORT' undeclared
    Nils> (first use this function) error: command 'gcc' failed with
    Nils> exit status 1
 
    Nils> Where can I find wxPython.h ?

Nils, if you don't specifically want the wxagg animated blit
functionality (as described here
http://www.scipy.org/wikis/topical_software/Animations), you can set
'BUILD_WXAGG = 0' in setup.py.  Otherwise, you'll need to get the
devel headers as others have suggested.

Kevin, Do you think it would be possible to make the BUILD_WXAGG logic
a little smarter so that it doesn't kill the build process?  Or
perhaps set BUILD_WXAGG to False by default.  I'm afraid this one will
bite a lot of people who have wxpython installed but not the devel
headers (as noted in previous discussions, the debian devel packages
appear broken with respect to wxPython.h).  

JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> So, the big question is: is it OK, or at least potentially
    Eric> OK, to change the pylab API for contour and contourf so that
    Eric> they return a single object instead of a tuple?  

It's fine with me.  contour users are mostly power users, so they will
adapt, and the functionality is still relatively new so it is not too
deeply ingrained in people's apps.  As I recall, I dumped most of the
contour functionality into the ContourHelpers class just to clean up
axes.py, which was beginning to be dominated by all the contour code.

I think the idea of having a single object that controls all the
contour functionality is a good one, because it is easier to extend
w/o breaking argument passing symantics.  In general, I think this
would be a good idiom for all plot objects (LinePlot, ScatterPlot,
ContourPlot, ImagePlot, etc...)

FYI, I applied you in/out ticks patch to CVS a couple of days ago.

JDH

Hello Mark,
Hello everyone,

I wrote myself a little program which juggled five commands in all possible
orders saving each plottingresult in a png. What I could see was that (with
autoscale_on=False) the commands

  imshow(something),
  plot(something)
  axis('scaled')
  axis('equal')
  axis([-2,2,-3,3]))

had to obey two rules. Then and only then the plot looked like I wanted 
(i.e. it had the correct limits given by axis([...]) and a circle looked
like a circle).
 (i) plot()   has to be before axis([-2,2,-3,3])
(ii) imshow() has to be before axis([-2,2,-3,3])

I think (i) everyone knows from everyday experience with MPL. Then (ii)
doesn't suprise too much.

Remark 1)
I put axis('equal') AND axis('scaled') in, just to check out
if everything works fine. It seems to me that axis('scaled') overrules
axis('equal').
In other words: I suppose axis('equal') doesn' set fixLimits=False.
I - preferring axis('scaled') - doesn't find this to bad. But nevertheless
it could be confusing to the user who prefers the other option ... on the
other hand: Propably no-one uses axis('equal') AND axis('scaled') in one
program (except me doing a 120 permutations ;-)

Remark 2)
Still: I can't become a really friend of this. If autoscale_on=True I would
understand (i) and (ii). But it is False. When plotting doesn't autoscale
why are the limits changed? In other words: Why (i) and (ii)? You could
propably say: We already talked about the difference in
  axis('equal')
  axis([-2,2,-3,3])
and
  axis([-2,2,-3,3])
  axis('equal').
But this is not true for axis('scaled'). Here the order doesn't play a role
(At least I saw this in a seperate example and I also couldn't figure out
that the order played a role for 'scaled' in my permutations - notice the
"Then and only then" before (i) and (ii)!)

That's as far as I came right now.
Bye,
Martin

PS: I don't know if this permutation-doing program is of any use to you.
That's why I haven't attached it. If you would like to have it - let me know
... but I wouldn't exhibit it in the Louvre if you know what I mean ;-)

-- 
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner

Nils Wagner wrote:

>>>Unfortunately, SuSE 9.1 comes without python-wxGTK-devel.
>>>Which rpm's (from wxpython.org) are necessary and can be used with SuSE
>>>9.1 ?
>>>
>>
>>On 9.2 I'm using those:
>>
>>wxPython2.6-gtk2-unicode-2.6.1.0-1_py2.3
>>wxPython2.6-devel-gtk2-unicode-2.6.1.0-1_py2.3
>>wxPython-common-gtk2-unicode-2.6.0.1-1_py2.3
>>
> 
> Sorry, I cannot find SuSE specific rpm's but only rpm's for Fedora,
> Mandrake and Red Hat.
>  http://www.wxpython.org/download.php
> 

There aren't any for SuSE, I'm using the RH9 ones.
Christian

Hi

Well I'm running a 2.6.11 testing kernel (due to some hardware problems
under 2.6.8) but I fetch all my software (via apt-get) from the stable
archives. I'm no Debian expert but I know that apt-get and dpkg perform
good dependency checking when you install a .deb and should tell you if
some required packages are too old. I had no problems with the two
packages and my mpl is running fine. Note that I installed

libpixman1_0.1.5-1_i386.deb
libcairo1_0.4.0-1_i386.deb

but I guess that the newer versions now available should also do the job.

cheers,
steve


Noel O'Boyle wrote:
> Thanks Steve,
> I prefer to use .debs where possible. Is it risky to use packages from
> unstable? I don't want to return to an rpm nightmare.
> 
> Regards,
> Noel
> 
> On Thu, 2005-09-08 at 11:19 +0200, Steve Schmerler wrote:
> 
>>Noel O'Boyle wrote:
>>
>>>Is the debian package for matplotlib broken??
>>>
>>>I found the following error when trying to install the debian package
>>>for matplotlib as per the instructions at the bottom of
>>>http://matplotlib.sourceforge.net/installing.html.
>>>
>>>apt-get install python-matplotlib python-matplotlib-doc
>>>"The following packages have unmet dependencies:
>>>  python-matplotlib: Depends: python2.3-matplotlib (= 0.82-1) but it is
>>>not going to be installed
>>>E: Broken packages"
>>>
>>>I then tried apt-get install python2.3-matplotlib:
>>>"The following packages have unmet dependencies:
>>>  python2.3-matplotlib: Depends: libcairo1 but it is not installable
>>>E: Broken packages"
>>>
>>>I then tried apt-get install libcairo1:
>>>"Package libcairo1 is not available, but is referred to by another
>>>package.
>>>This may mean that the package is missing, has been obsoleted, or
>>>is only available from another source
>>>E: Package libcairo1 has no installation candidate"
>>>
>>>Regards,
>>>Noel
>>>
>>>
>>
>>
>>Hi
>>
>>Seems that you have compiled mpl yourself by now. Anyway if you (or 
>>others) are still interested in installing the .debs from 
>>http://anakonda.altervista.org:
>>
>>I had to download and install libpixman1*.deb and libcairo1*.deb from 
>>debian.org (apt-get didn't find any of these since I'm running a sarge 
>>stable). Meanwhile there is a
>>libcairo2_1.0.0-2_i386.deb in unstable and a ibpixman1_0.1.6-1_i386.deb 
>>in testing.
>>
>>After installing these I could do
>>
>>apt-get install python2.3-matplotlib python-matplotlib-data 
>>python-matplotlib-doc
>>
>>cheers,
>>steve
> 
> 

Nils Wagner wrote:
> Christian Kristukat wrote:
> 
>>Nils Wagner wrote:
>>
>>>Hi all,
>>>
>>>I am trying to build matplotlib from cvs on SuSE 9.1.
>>>
>>>python setup.py build results in
>>>
>>>src/_wxagg.cpp:55:34: wx/wxPython/wxPython.h: No such file or directory
>>>src/_wxagg.cpp: In member function `Py::Object
>>>_wxagg_module::convert_agg_to_wx_image(const Py::Tuple&)':
>>>src/_wxagg.cpp:105: error: `wxPyConstructObject' undeclared (first use
>>>this function)
>>>src/_wxagg.cpp:105: error: (Each undeclared identifier is reported only
>>>once for each function it appears in.)
>>>src/_wxagg.cpp: In member function `Py::Object
>>>_wxagg_module::convert_agg_to_wx_bitmap(const Py::Tuple&)':
>>>src/_wxagg.cpp:129: error: `wxPyConstructObject' undeclared (first use
>>>this function)
>>>src/_wxagg.cpp: In function `void init_wxagg()':
>>>src/_wxagg.cpp:260: error: `wxPyCoreAPI_IMPORT' undeclared (first use
>>>this function)
>>>error: command 'gcc' failed with exit status 1
>>> 
>>>Where can I find wxPython.h ?
>>>
>>>cvs/matplotlib> rpm -qi python-wxGTK
>>
>>Have you installed python-wxGTK-devel as well? The include files
>>should be there. Btw. the rpm packages from wxpython.org work without
>>problems on SuSE and are more recent than those shipped.
>>
> 
> Unfortunately, SuSE 9.1 comes without python-wxGTK-devel.
> Which rpm's (from wxpython.org) are necessary and can be used with SuSE
> 9.1 ?
> 

On 9.2 I'm using those:

wxPython2.6-gtk2-unicode-2.6.1.0-1_py2.3
wxPython2.6-devel-gtk2-unicode-2.6.1.0-1_py2.3
wxPython-common-gtk2-unicode-2.6.0.1-1_py2.3

Christian

> On my linux box (Debian Sarge, Python 2.3, Matplotlib 0.82) the first 
> example, text(0.5, 0.5, u'\u03bb'), correctly shows a lambda, but the 
> second, text(0.5, 0.5, u'\u03bb'.encode('utf8')), only shows 2 small 
> boxes. Perhaps you do not have all the required fonts installed?

I am not sure what fonts need to be installed. Actually I thought Matplotlib
brings its own fonts... 

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

On my linux box (Debian Sarge, Python 2.3, Matplotlib 0.82) the first 
example, text(0.5, 0.5, u'\u03bb'), correctly shows a lambda, but the 
second, text(0.5, 0.5, u'\u03bb'.encode('utf8')), only shows 2 small 
boxes. Perhaps you do not have all the required fonts installed?

I am using the AGG backend and I am having issues with displaying unicode
characters in MPL on a Linux box. Instead of the actual character I see only
a placeholder/square symbol. E.g. the following command 

text(0.5, 0.5, u'\u03bb')

correctly shows the small greek letter lambda on my windows machine, but on
Linux, I get only a placeholder. I also tried

text(0.5, 0.5, u'\u03bb'.encode('utf8'))

and some other encodings but the result is the same. The python default
encoding is UTF-8 on both systems.

Is this maybe due to the font not being able to display this character (not
sure whether different fonts are used on different OSs) or am I making some
encoding mistake?

Thanks in advance,
Sascha

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

Hello everyone,

Arnd Baecker and I tried a while to enlarge the thickness of tick-lines. 
One of our presumptions was:

  ax = gca()
  xticks = ax.xaxis.get_ticklines()
  setp(xticks, linewidth= 4)

This was not working.
But we finally found a way to do so. To do the desired enlargement we had to
edit the 'lines.py'-file. Because of the ticks also just being lines we
added something to the methods

  _draw_tickleft(self, renderer, gc, xt, yt)
  _draw_tickright(self, renderer, gc, xt, yt)
  _draw_tickup(self, renderer, gc, xt, yt)
  _draw_tickdown(self, renderer, gc, xt, yt).

Right after each 

  offset = renderer.points_to_pixels(self._markersize)

(which as far as we know sets the lenght of the ticks with help of the
rc-file via some minor detours)
we wrote a 

  gc.set_linewidth(self._linewidth).

Now the 

  ax = gca()
  xticks = ax.xaxis.get_ticklines()
  setp(xticks, linewidth= 4)

did work well!

Now there are three more things to ask:

a) Is there any drawback? We just used the self._linewidth without really
knowing what it was for. Could it be that some user sets a parameter
somewhere to change some other linewidth and changes the tickwidth "en
passant"?
b) In behalf of unification it would possibly be better to add this option
to the .matplotlibrc-file in the neighbourhood of

  tick.major.size     : 4      # major tick size in points.

(As far as I can see this means changeing the Class Tick's __init__ placed
in axis.py a little bit.)
c) Now it is possible to change 'lw'. Should it also be possible to change
'color', 'linestyle'?

Bye,
Martin

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Dear all,

I have just succeeded in compiling and installing matplotlib on Debian
Sarge. I look forward to many hours of happy graphing, etc.

However, I think that there are a few things which could be done to make
the whole procedure less painful for users.

I compiled with the Tk backend. But when I tried to import pylab, it
kept looking for the GTK backend. After several recompilations, I
realised that matplotlibrc still thought the default backend was GTKAgg.
I changed this to TKAgg and all was fine.

Problems/Solutions:
(1) If I don't compile GTK, please don't make it the default. Or, at
least, in the installation procedure please tell me to change the
default backend in matplotlibrc (or even, just tell me about
matplotlibrc).
(2) If I need to edit setup.py, please include the list of possible
options beside each of the relevant lines.
(3) If I need to edit matplotlibrc, please include the list of possible
options beside each of the relevant lines. I had to look up the correct
spelling for TkAgg in the source (the User Guide variously refers to
tkagg, Tkagg, TkAgg) - there is an easier way.

I appreciate all of the hard work by the matplotlib team and hope that
my comments are helpful,

Regards,
Noel O'Boyle.

John, Jeff,

As I mentioned a couple weeks ago, I found that the CVS change to 
colorbar breaks contourf if called with explicit colors rather than a 
colormap.  I think this is just a symptom of deeper problems in 
contour.py, so I have been trying to improve the whole system before 
dealing with the specific colorbar problem.  I have found it very 
difficult to keep track of what is going on in the present system, 
particularly with respect to the "mappable" object that gets tacked onto 
the list of collections that contour and contourf return.  I think the 
root of the problem is the tension between OO design and the non-OO 
matlab compatibility of the present contour and contourf functions, 
combined with the minimally OO construction of the ContourHelper class 
(which is mostly a package of functions).  Now, the functions return 
(levs, collections), where levs is the list of contour levels and 
collections is a silent_list of collections with an attached 
ContourMappable object.  What I want to do instead is return a single 
object that includes everything useful; it inherits from ScalarMappable 
(like collections do), it includes the levels, the list of collections, 
and all the various relevant attributes of the contour plot.  Passing 
this object to a colorbar function or a clabel function then makes it 
much easier for these functions to do the right thing--they get the 
necessary information in a single straightforward package.

So, the big question is: is it OK, or at least potentially OK, to change 
the pylab API for contour and contourf so that they return a single 
object instead of a tuple?  I am part-way there, and I think going the 
rest of the way would be good for the long-term usability and 
maintainability of mpl.  But I don't want to go the rest of the way, 
which will affect many files and also break some users' programs, if 
this is judged to be too radical a change, or otherwise undesirable.

Eric