matplotlib-devel Mailing List for matplotlib

Erik Tollerud wrote:
> I tested this on 0.91.2 on Ubuntu Gutsy, and wx 2.8.7.1, and found
> that when I bring up a new window, I see a black canvas and it doesn't
> draw any of the matplotlib objects until I do something like resizing
> that must explicitly call a draw at some point.
yup, same here.
I'm using wxAgg, and FigureCanvas.draw() just doesn't seem to be getting 
called when I call Figure.draw()
It looks like it's designed to work the other way -- the Window needs to 
call self.figure.draw(self.renderer) when it wants the image drawn. 
There is an efficiency to this, as the figure doesn't get rendered until 
the GUI toolkit needs it. However, having it re-render on every Paint 
call isn't right either.
So how should this work? I'd like to be able to call Figure.draw(), and 
have the figure re-draw itself - but then it needs to be able to tell 
the backend Canvas that it needs to be drawn.
It seems that the figure needs to keep a flag that indicated when it is 
"dirty", then the paint handler could check that, and call draw if need 
be. Is there one already?
This all seems a bit awkward though. I've written a bunch of double 
buffered code, and I try to do it like this:
The Paint handler only blits.
There is a draw routine that actually draws the off-screen bitmap. It is 
called:
 - when the bitmap is new, like in a Re-size event
 - when the drawing changes.
In the MPL case, then, it seems that figure.draw() should call that draw 
routine, but maybe it doesn't know anything about its canvas. Ah -- ye 
sit does - figure.canvas.
OK, so a draw_event is getting called, which I guess is where the 
drawing should happen, but I'm getting lost now!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I tested this on 0.91.2 on Ubuntu Gutsy, and wx 2.8.7.1, and found
that when I bring up a new window, I see a black canvas and it doesn't
draw any of the matplotlib objects until I do something like resizing
that must explicitly call a draw at some point. This may be why it's
in there... perhaps some sort of checking to see if any draw has been
performed yet?
On Mon, Mar 31, 2008 at 7:58 AM, Gregor Thalhammer
<gre...@gm...> wrote:
> Dear developers,
>
> I discovered that in backend_wx.py in _onPaint(), the callback function
> for repainting a matplotlib figure, every time a repaint is done also
> the bitmap is rerendered:
>
> backend_wx.py/_onPaint():
> ...
> # Render to the bitmap
> self.draw(repaint=False)
> ...
>
> This also affects the behaviour of the wxagg backend. Rerendering and
> therefore also repainting gets quite slow if, e.g., images are included
> in the figure. I can see this by simply dragging another window across
> the matplotlibfigure. Commenting out the rerendering I get a much
> smoother behaviour. I could not observe problems except that sometimes
> some parts of the figure are not properly repainted if the matplotlib
> figure is in the background (I only tested the wxagg backend). Therefore
> it seems that this rerendering every time a repaint is performed is not
> really necessary and should be avoided.
>
> I tested this on matplotlib 0.91.2 on WinXP, Python 2.5, wx 2.8.7. I
> checked that in the current svn version the _onPaint() function is
> unchanged.
>
> Gregor
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
eto...@uc...

Dear developers,
I discovered that in backend_wx.py in _onPaint(), the callback function 
for repainting a matplotlib figure, every time a repaint is done also 
the bitmap is rerendered:
backend_wx.py/_onPaint():
...
# Render to the bitmap
self.draw(repaint=False)
...
This also affects the behaviour of the wxagg backend. Rerendering and 
therefore also repainting gets quite slow if, e.g., images are included 
in the figure. I can see this by simply dragging another window across 
the matplotlibfigure. Commenting out the rerendering I get a much 
smoother behaviour. I could not observe problems except that sometimes 
some parts of the figure are not properly repainted if the matplotlib 
figure is in the background (I only tested the wxagg backend). Therefore 
it seems that this rerendering every time a repaint is performed is not 
really necessary and should be avoided.
I tested this on matplotlib 0.91.2 on WinXP, Python 2.5, wx 2.8.7. I 
checked that in the current svn version the _onPaint() function is 
unchanged.
Gregor

Hi Michael!
Thanks a lot for a thourough reply. I've CCed Saroj, the GSoC
applicant. I hope he'll succeed.
If you could mentor, that'd be great. Do you want to mentor officially
or unofficially? If officially, you need to be a PSF mentor (let me
know, I'll help
you do the administration). If unofficially, I can be the mentor and
you can help Saroj with the TeX part of his app.
Actually, if it's not a problem for you, I'd prefer the official way,
for example you can be a backup mentor. Also you'll get a google GSoC
t-shirt. :)
Ondrej
On Fri, Mar 28, 2008 at 2:22 PM, Michael Droettboom <md...@st...> wrote:
> Well, that work has gone from a "paid to work on it" to a "hobby
> project", so it's harder to find the time.
>
> In terms of "math rendering" features, it's pretty complete. It's not
> 100% of TeX, and it never will be, but it's able to do most of the
> really common things.
>
> I would like to see this as an independent Python package. The pieces
> that are missing to do this are:
>
> Freetype wrappers: One could just extract the existing freetype wrappers
> in mpl. But that duplicates that code in two places, and those wrappers
> were built on a sort of "as needed" basis, and wouldn't be considered
> complete for any other purpose. (Maybe not a bad thing, though). The
> ctypes-based wrapper in pyglet is a candidate, but last time I looked,
> it's missing some features to extract the glyph metadata that mathtext
> needs. Plus, there always seem to be version mismatch problems with
> ctypes-based stuff, at least for me. I'd still love to see a proper C
> freetype wrapper as an independent project. PIL has a very basic one,
> that doesn't even come close to what we need -- but perhaps it's a
> starting point that could be extended.
>
> A basic bitmap rendering engine: It needs to be able to take the glyph
> buffers from freetype and blend them onto an image, as well as draw
> filled rectangles. So it doesn't need to be anything as full-blown as
> Agg, and could probably be built on top of numpy or PIL, or as a C
> extension, but pure Python ain't gonna cut it. This should then
> integrate with PILand/or pyglet to save PNG, JPEG files etc.
>
> Non-bitmap backends: These would be subsets of the matplotlib backends,
> but we would probably want the basic ability to write out PS, PDF and
> SVG etc. This is probably the biggest part of matplotlib that would
> need to be "pulled out", and the trickiest. It would still be useful to
> just have the "generic" vector description of the equations from
> mathtext and consider these backends as a secondary feature for later.
> An HTML backend that does glyph placement with CSS and Canvas would
> probably also be very useful for webpage output.
>
> So, that's a lot of work there, but it's all doable and should be fairly
> unsurprising. I'd be happy to unofficially help mentor someone doing a
> GSoC project on this, but I don't think I'll have time to do all of the
> work myself in the near future.
>
> Cheers,
> Mike
>
>
>
> Ondrej Certik wrote:
> > Hi,
> >
> > was there any new progress for the TeX engine since our last conversation?
> >
> > We got a GSoC application for SymPy, that (among other things) would
> > try to disentangle the TeX engine from matplotlib, so that it can be
> > easily used from other projects as well.
> >
> > What are your intentions with the engine - do you still hack on it, or
> > do you consider it more or less complete for your needs? I don't want
> > to have 2 incompatible engines in python - but if you are not going to
> > hack on it (much), then I think it makes sense to create a new project
> > for this and you can just include it. Because I think it's an
> > extremely cool and useful thing.
> >
> > And we want to have this in sympy too, because we have quite nice
> > ascii art printing, so having nice graphics printing is just a next
> > step.
> >
> > Ondrej
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

Well, that work has gone from a "paid to work on it" to a "hobby 
project", so it's harder to find the time.
In terms of "math rendering" features, it's pretty complete. It's not 
100% of TeX, and it never will be, but it's able to do most of the 
really common things. 
I would like to see this as an independent Python package. The pieces 
that are missing to do this are:
Freetype wrappers: One could just extract the existing freetype wrappers 
in mpl. But that duplicates that code in two places, and those wrappers 
were built on a sort of "as needed" basis, and wouldn't be considered 
complete for any other purpose. (Maybe not a bad thing, though). The 
ctypes-based wrapper in pyglet is a candidate, but last time I looked, 
it's missing some features to extract the glyph metadata that mathtext 
needs. Plus, there always seem to be version mismatch problems with 
ctypes-based stuff, at least for me. I'd still love to see a proper C 
freetype wrapper as an independent project. PIL has a very basic one, 
that doesn't even come close to what we need -- but perhaps it's a 
starting point that could be extended.
A basic bitmap rendering engine: It needs to be able to take the glyph 
buffers from freetype and blend them onto an image, as well as draw 
filled rectangles. So it doesn't need to be anything as full-blown as 
Agg, and could probably be built on top of numpy or PIL, or as a C 
extension, but pure Python ain't gonna cut it. This should then 
integrate with PILand/or pyglet to save PNG, JPEG files etc.
Non-bitmap backends: These would be subsets of the matplotlib backends, 
but we would probably want the basic ability to write out PS, PDF and 
SVG etc. This is probably the biggest part of matplotlib that would 
need to be "pulled out", and the trickiest. It would still be useful to 
just have the "generic" vector description of the equations from 
mathtext and consider these backends as a secondary feature for later. 
An HTML backend that does glyph placement with CSS and Canvas would 
probably also be very useful for webpage output.
So, that's a lot of work there, but it's all doable and should be fairly 
unsurprising. I'd be happy to unofficially help mentor someone doing a 
GSoC project on this, but I don't think I'll have time to do all of the 
work myself in the near future.
Cheers,
Mike
 
Ondrej Certik wrote:
> Hi,
>
> was there any new progress for the TeX engine since our last conversation?
>
> We got a GSoC application for SymPy, that (among other things) would
> try to disentangle the TeX engine from matplotlib, so that it can be
> easily used from other projects as well.
>
> What are your intentions with the engine - do you still hack on it, or
> do you consider it more or less complete for your needs? I don't want
> to have 2 incompatible engines in python - but if you are not going to
> hack on it (much), then I think it makes sense to create a new project
> for this and you can just include it. Because I think it's an
> extremely cool and useful thing.
>
> And we want to have this in sympy too, because we have quite nice
> ascii art printing, so having nice graphics printing is just a next
> step.
>
> Ondrej
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
was there any new progress for the TeX engine since our last conversation?
We got a GSoC application for SymPy, that (among other things) would
try to disentangle the TeX engine from matplotlib, so that it can be
easily used from other projects as well.
What are your intentions with the engine - do you still hack on it, or
do you consider it more or less complete for your needs? I don't want
to have 2 incompatible engines in python - but if you are not going to
hack on it (much), then I think it makes sense to create a new project
for this and you can just include it. Because I think it's an
extremely cool and useful thing.
And we want to have this in sympy too, because we have quite nice
ascii art printing, so having nice graphics printing is just a next
step.
Ondrej

On Tue, Mar 25, 2008 at 06:04:41PM -0500, bryce hendrix wrote:
> How stable is the API? We (Enthought) use endo, a custom tool build on 
> top of docutils, to generate our docs currently. We have talked about 
> changing tools in the past, but the need to extend the tools to 
> understand Traits has held us back.
Sphinx is not automated API documentation, like Endo or Epidoc. It is for
manual writing of documentation. It does not compete with Endo or Epidoc,
but complements them by taking a set of rst files and compiling both a
set of searchable web pages, and an indexed pdf for print.
Gaël

Fernando Perez wrote:
> Hey guys,
>
> sorry for the silence, mostly on travel. I just wanted to mention
> that the sphinx machinery seems quite nice, in particular it produces
> both high-quality pdf and client-side searchable html. This is great,
> because it measn that the entire doc set is automatically searchable
> for the users in a convenient manner, even when running offline and
> without the need for any special server config (and in a more
> civilized fashion than brute-forcing grep searches).
>
> Also, Sympy (led by Ondrej), ipython, mayavi2 and at least
> neuroimaging.scipy.org have all committed to using this system, and we
> hope in the future numpy and scipy will follow suit (at least Jarrod
> Millman and Stefan van der Walt, who are doing lots of work on those,
> are fully on board with the idea). It would be really nice if all
> these projects could offer unified, consistent docs to their users,
> and having MPL jump along would be great.
> 
How stable is the API? We (Enthought) use endo, a custom tool build on 
top of docutils, to generate our docs currently. We have talked about 
changing tools in the past, but the need to extend the tools to 
understand Traits has held us back.
Thanks,
Bryce

Hey guys,
sorry for the silence, mostly on travel. I just wanted to mention
that the sphinx machinery seems quite nice, in particular it produces
both high-quality pdf and client-side searchable html. This is great,
because it measn that the entire doc set is automatically searchable
for the users in a convenient manner, even when running offline and
without the need for any special server config (and in a more
civilized fashion than brute-forcing grep searches).
Also, Sympy (led by Ondrej), ipython, mayavi2 and at least
neuroimaging.scipy.org have all committed to using this system, and we
hope in the future numpy and scipy will follow suit (at least Jarrod
Millman and Stefan van der Walt, who are doing lots of work on those,
are fully on board with the idea). It would be really nice if all
these projects could offer unified, consistent docs to their users,
and having MPL jump along would be great.
Cheers,
f

Hi,
I think that "collection._alpha = self.alpha" (or something better)
are missing in ContoutSet.__init__, because _alpha from collections
(Line or Poly) overrides the alpha value the color of
"collection.set_color(color)" found in method "changed" of ContourSet.
Therefore, alpha doesn't work for contours (filled or not).
Nota: If "collection.set_alpha" is used, it fails with line contouring
because self._edgecolors is an empty list.
I hope it can help.
-- 
Stephane Raynaud

On Tue, Mar 25, 2008 at 7:38 AM, Darren Dale <dar...@co...> wrote:
> There was some discussion a while back concerning upcoming changes to the mpl
> documentation: moving the docs into the trunk and updating the website. I
> can't find the thread now, could anyone summarize the current thinking?
> Ondrej Certik recently implemented a sphinx-based documentation for ipython1
> (see http://ipython.scipy.org/doc/ipython1/html/ and
> http://ipython.scipy.org/doc/ipython1/ipython1.pdf), I wonder if we should
> consider doing the same for matplotlib.
I'm definitely up for this or something close to it. We definitely
want rest based docs which live in svn alongside the src distribution.
 If something like sphinx on top of it makes for better documents, I'm
all for it. You may have seen that over the weekend I added a couple
of API rst documents to the doc subdir, with some basic make.py
support for building them into PDFs. If you or anyone would like to
take a stab at getting a sphinx implementation going, have at it.
JDH

For those of you wondering "what is sphinx?" this will save you a few
seconds of searching: http://sphinx.pocoo.org/
The output looks really nice.
Darren Dale wrote:
> There was some discussion a while back concerning upcoming changes to the mpl 
> documentation: moving the docs into the trunk and updating the website. I 
> can't find the thread now, could anyone summarize the current thinking? 
> Ondrej Certik recently implemented a sphinx-based documentation for ipython1 
> (see http://ipython.scipy.org/doc/ipython1/html/ and 
> http://ipython.scipy.org/doc/ipython1/ipython1.pdf), I wonder if we should 
> consider doing the same for matplotlib.
> 
> I haven't had nearly as much time to contribute to matplotlib as I did when I 
> was still in grad school, but I think I will have some free time starting in 
> May and would like to contribute some more over the summer. Now is probably a 
> good time to start considering summer projects.
> 
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

There was some discussion a while back concerning upcoming changes to the mpl 
documentation: moving the docs into the trunk and updating the website. I 
can't find the thread now, could anyone summarize the current thinking? 
Ondrej Certik recently implemented a sphinx-based documentation for ipython1 
(see http://ipython.scipy.org/doc/ipython1/html/ and 
http://ipython.scipy.org/doc/ipython1/ipython1.pdf), I wonder if we should 
consider doing the same for matplotlib.
I haven't had nearly as much time to contribute to matplotlib as I did when I 
was still in grad school, but I think I will have some free time starting in 
May and would like to contribute some more over the summer. Now is probably a 
good time to start considering summer projects.
Darren

On Monday 24 March 2008 08:09:56 am Michael Droettboom wrote:
> Ted Drain wrote:
> > I've been investigating performance problems we've been having w/ the Qt
> > backends. One problems is that zooming takes forever. I've put a lot of
> > timing loops into the backends to see where things are happening and
> > found a couple of interesting items.
> >
> > The first is that agg seems to get much slower as you zoom in. The agg
> > draw time goes up as the zoom level goes up. These are plots that are
> > completely done w/ the Ellipse patch. Using the Arc patch helps but is
> > about 10% slower when not zooming.
>
> Out of curiosity -- are you using matplotlib 0.91.2, or the SVN trunk?
> The SVN trunk has about 25% faster out-of-bounds vertex removal that
> should improve this.
>
> > The second (and reason for the email), is that the QtAgg backends are
> > redrawing the whole plot twice when zooming w/ the mouse.
>
> It looks like Darren has addressed this part...
That was a different redundant draw() call that Ted reported earlier. I just 
committed this fix, thanks Ted.
Darren

Ted Drain wrote:
> I've been investigating performance problems we've been having w/ the Qt
> backends. One problems is that zooming takes forever. I've put a lot of
> timing loops into the backends to see where things are happening and found a
> couple of interesting items. 
>
> The first is that agg seems to get much slower as you zoom in. The agg draw
> time goes up as the zoom level goes up. These are plots that are completely
> done w/ the Ellipse patch. Using the Arc patch helps but is about 10%
> slower when not zooming. 
> 
Out of curiosity -- are you using matplotlib 0.91.2, or the SVN trunk? 
The SVN trunk has about 25% faster out-of-bounds vertex removal that 
should improve this.
> The second (and reason for the email), is that the QtAgg backends are
> redrawing the whole plot twice when zooming w/ the mouse. 
It looks like Darren has addressed this part...
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Mar 21, 2008 at 8:21 AM, Michael Droettboom <md...@st...> wrote:
> It doesn't look like a faulty X setup, and since you *do* get a window,
> it's unlikely it's a Tkinter problem.
>
> The fishy thing here is that _tkagg should be a C extension, have a .so
> file extension and have only the following members -->
Yes, that is very odd. Did we every have a _tkagg python module in
the old days (Todd?). If so, and fiarce is installing over an old
distro, he may be getting into a conflict between a *.so and a *.py
module in the same directory. One thing to try is to the "build" dir
in the src distribution and most importantly site-packages/matplotlib
and try for a clean install. And use ubuntu rather than gentoo <wink>
JDH

I've been investigating performance problems we've been having w/ the Qt
backends. One problems is that zooming takes forever. I've put a lot of
timing loops into the backends to see where things are happening and found a
couple of interesting items. 
The first is that agg seems to get much slower as you zoom in. The agg draw
time goes up as the zoom level goes up. These are plots that are completely
done w/ the Ellipse patch. Using the Arc patch helps but is about 10%
slower when not zooming. 
The second (and reason for the email), is that the QtAgg backends are
redrawing the whole plot twice when zooming w/ the mouse. The problem is
the files:
backend_qt.py
backend_qt4.py
The method mouseReleaseEvent calls draw() at the end of it. This seems to
be redundant. None of the other backends call draw at the end of their
mouse release code. The release_zoom method in the toolbar already does a
draw() call which handles the zoom. In addition, this mouseReleaseEvent
code triggers a draw whenever you click anywhere in the figure.
Does anyone have any idea why the qt backends should have a draw in the
mouse release when the others don't?
Ted

On Thu, Mar 13, 2008 at 3:17 PM, Mark E. Hamilton <mh...@sa...> wrote:
> I'm getting the traceback shown below in _get_configdir. I've attached a
> patch for cutils.py
Thanks Mark -- I just committed this fix to the svn trunk,
Thanks,
JDH

Michael Droettboom wrote:
> The fishy thing here is that _tkagg should be a C extension, have a .so 
> file extension and have only the following members -->
> 
> >>> dir(_tkagg)
> ['__doc__', '__file__', '__name__', '_pyobj_addr', 'tkinit']
> 
> tkagg (without the underscore), on the other hand, is a true Python 
> module, would have a .pyc extension and all of the members you posted.
> 
> So, somehow, tkagg got renamed to _tkagg on your system. I'm not sure 
> how the build script may have done that. Does removing
> 
> /usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc
> 
> help? (It's generally safe to remove .pyc files since they are 
> regenerated by the Python compiler). Do you have a _tkagg.py sitting in 
> that directory?
> 
> Did you build matplotlib from the source tarball, a Gentoo port (or 
> whatever they're called), or some other way?
Just as a an FYI, on my Gentoo box here, with matplotlib 0.91.2 
installed from Portage, I have: 
/usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.so
And I don't have any problems with the TkAgg backend.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

fiacre wrote:
> root@~ $ emerge --searchdesc tk-devel
> Searching...
> [ Results for search key : tk-devel ]
> [ Applications found : 0 ]
> 
> 
> Evidently, gentoo has no tk-devl packages -- only gtk-devel ... which 
> leads me to believe the problem with the install has to do with the fact 
> that I am not use Gtk.
> 
Since gentoo is a source-based distro, there are no *-devel packages, 
since the headers always get installed with the library itself. Binary 
distros have the *-devel packages so that only those people who wish to 
do development (ie. compile) need to install the headers.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

It doesn't look like a faulty X setup, and since you *do* get a window, 
it's unlikely it's a Tkinter problem.
The fishy thing here is that _tkagg should be a C extension, have a .so 
file extension and have only the following members -->
 >>> dir(_tkagg)
['__doc__', '__file__', '__name__', '_pyobj_addr', 'tkinit']
tkagg (without the underscore), on the other hand, is a true Python 
module, would have a .pyc extension and all of the members you posted.
So, somehow, tkagg got renamed to _tkagg on your system. I'm not sure 
how the build script may have done that. Does removing
 /usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc
help? (It's generally safe to remove .pyc files since they are 
regenerated by the Python compiler). Do you have a _tkagg.py sitting in 
that directory?
Did you build matplotlib from the source tarball, a Gentoo port (or 
whatever they're called), or some other way?
If you built yourself, (even if the above suggestion worked), could you 
try cleanly rebuilding again by:
 1. deleting the build directory under the source tree
 2. deleting /usr/lib/python2.5/site-packages/matplotlib
 3. "python setup.py install"
and let us know if that worked?
Cheers,
Mike
Darren Dale wrote:
> Do you have the tk-devel packages installed? When you run setup.py, there is a 
> report at the beginning which lists all the required and optional 
> dependencies, would you post that?
>
> On Friday 21 March 2008 08:52:40 am fiacre wrote:
> 
>> I agree -- I don't believe it built correctly either ...
>>
>> Python 2.5.1 (r251:54863, Mar 20 2008, 04:03:41)
>> [GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>> >>> from matplotlib.backends import _tkagg
>> >>> _tkagg.__file__
>>
>> '/usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc'
>>
>> >>> dir(_tkagg)
>>
>> ['AxisMenu', 'Figure', 'FigureCanvasAgg', 'FigureCanvasBase',
>> 'FigureCanvasTkAgg', 'FigureManager', 'FigureManagerBase',
>> 'FigureManagerTkAgg', 'FileDialog', 'Gcf', 'GraphicsContextBase',
>> 'NavigationToolbar', 'NavigationToolbar2', 'NavigationToolbar2TkAgg',
>> 'PIXELS_PER_INCH', 'RendererBase', 'SubplotTool', 'Tk', '__builtins__',
>> '__doc__', '__file__', '__name__', 'asarray', 'backend_version',
>> 'cursord', 'cursors', 'division', 'draw_if_interactive', 'enumerate',
>> 'error_msg_tkpaint', 'is_string_like', 'math', 'matplotlib',
>> 'new_figure_manager', 'os', 'raise_msg_to_str', 'rcParams', 'round',
>> 'show', 'sys', 'tkagg', 'verbose', 'windowing']
>>
>>
>>
>> I don't see anything obviously wrong though -- I am wondering if my X
>> setup is faulty.
>>
>> Thanks!
>>
>> Michael Droettboom wrote:
>> 
>>> It looks like the _tkagg C extension didn't build correctly -- it
>>> really should have a tkinit method.
>>>
>>> Can you please try the following and send me the output (inside the
>>> Python interpreter)...
>>>
>>> 
>>>>>> from matplotlib.backends import _tkagg
>>>>>> _tkagg.__file__
>>>>>> dir(_tkagg)
>>>>>> 
>>> Thanks!
>>>
>>> Mike
>>>
>>> fiacre wrote:
>>> 
>>>> I'm running Idle via X forwarding to my Windows desktop (running
>>>> Cygwin).
>>>>
>>>> I've installed tcl/tk and python with Tkinter as a backend.
>>>>
>>>> When I call pylab.show(), I always get the error :
>>>> >>> pylab.show()
>>>>
>>>> Exception in Tkinter callback
>>>> Traceback (most recent call last):
>>>> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
>>>> return self.func(*args)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
>>>> line 151, in resize
>>>> self.show()
>>>> File
>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
>>>> line 155, in draw
>>>> tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", line
>>>> 14, in blit
>>>> _tkagg.tkinit(id(tk), 0)
>>>> AttributeError: 'module' object has no attribute 'tkinit'
>>>>
>>>>
>>>> And an empty matplotlib window opens on my desktop.
>>>>
>>>>
>>>> Should I try gtk as a backend???
>>>>
>>>> TIA
>>>>
>>>> -- Andrew
>>>>
>>>> ------------------------------------------------------------------------
>>>> -
>>>>
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>> 
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

root@~ $ emerge --searchdesc tk-devel
Searching...
[ Results for search key : tk-devel ]
[ Applications found : 0 ]
Evidently, gentoo has no tk-devl packages -- only gtk-devel ... which 
leads me to believe the problem with the install has to do with the fact 
that I am not use Gtk.
Darren Dale wrote:
> Do you have the tk-devel packages installed? When you run setup.py, there is a 
> report at the beginning which lists all the required and optional 
> dependencies, would you post that?
>
> On Friday 21 March 2008 08:52:40 am fiacre wrote:
> 
>> I agree -- I don't believe it built correctly either ...
>>
>> Python 2.5.1 (r251:54863, Mar 20 2008, 04:03:41)
>> [GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>> >>> from matplotlib.backends import _tkagg
>> >>> _tkagg.__file__
>>
>> '/usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc'
>>
>> >>> dir(_tkagg)
>>
>> ['AxisMenu', 'Figure', 'FigureCanvasAgg', 'FigureCanvasBase',
>> 'FigureCanvasTkAgg', 'FigureManager', 'FigureManagerBase',
>> 'FigureManagerTkAgg', 'FileDialog', 'Gcf', 'GraphicsContextBase',
>> 'NavigationToolbar', 'NavigationToolbar2', 'NavigationToolbar2TkAgg',
>> 'PIXELS_PER_INCH', 'RendererBase', 'SubplotTool', 'Tk', '__builtins__',
>> '__doc__', '__file__', '__name__', 'asarray', 'backend_version',
>> 'cursord', 'cursors', 'division', 'draw_if_interactive', 'enumerate',
>> 'error_msg_tkpaint', 'is_string_like', 'math', 'matplotlib',
>> 'new_figure_manager', 'os', 'raise_msg_to_str', 'rcParams', 'round',
>> 'show', 'sys', 'tkagg', 'verbose', 'windowing']
>>
>>
>>
>> I don't see anything obviously wrong though -- I am wondering if my X
>> setup is faulty.
>>
>> Thanks!
>>
>> Michael Droettboom wrote:
>> 
>>> It looks like the _tkagg C extension didn't build correctly -- it
>>> really should have a tkinit method.
>>>
>>> Can you please try the following and send me the output (inside the
>>> Python interpreter)...
>>>
>>> 
>>>>>> from matplotlib.backends import _tkagg
>>>>>> _tkagg.__file__
>>>>>> dir(_tkagg)
>>>>>> 
>>> Thanks!
>>>
>>> Mike
>>>
>>> fiacre wrote:
>>> 
>>>> I'm running Idle via X forwarding to my Windows desktop (running
>>>> Cygwin).
>>>>
>>>> I've installed tcl/tk and python with Tkinter as a backend.
>>>>
>>>> When I call pylab.show(), I always get the error :
>>>> >>> pylab.show()
>>>>
>>>> Exception in Tkinter callback
>>>> Traceback (most recent call last):
>>>> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
>>>> return self.func(*args)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
>>>> line 151, in resize
>>>> self.show()
>>>> File
>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
>>>> line 155, in draw
>>>> tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
>>>> File
>>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", line
>>>> 14, in blit
>>>> _tkagg.tkinit(id(tk), 0)
>>>> AttributeError: 'module' object has no attribute 'tkinit'
>>>>
>>>>
>>>> And an empty matplotlib window opens on my desktop.
>>>>
>>>>
>>>> Should I try gtk as a backend???
>>>>
>>>> TIA
>>>>
>>>> -- Andrew
>>>>
>>>> ------------------------------------------------------------------------
>>>> -
>>>>
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>> 
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>
>
>
> 

Do you have the tk-devel packages installed? When you run setup.py, there is a 
report at the beginning which lists all the required and optional 
dependencies, would you post that?
On Friday 21 March 2008 08:52:40 am fiacre wrote:
> I agree -- I don't believe it built correctly either ...
>
> Python 2.5.1 (r251:54863, Mar 20 2008, 04:03:41)
> [GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> from matplotlib.backends import _tkagg
> >>> _tkagg.__file__
>
> '/usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc'
>
> >>> dir(_tkagg)
>
> ['AxisMenu', 'Figure', 'FigureCanvasAgg', 'FigureCanvasBase',
> 'FigureCanvasTkAgg', 'FigureManager', 'FigureManagerBase',
> 'FigureManagerTkAgg', 'FileDialog', 'Gcf', 'GraphicsContextBase',
> 'NavigationToolbar', 'NavigationToolbar2', 'NavigationToolbar2TkAgg',
> 'PIXELS_PER_INCH', 'RendererBase', 'SubplotTool', 'Tk', '__builtins__',
> '__doc__', '__file__', '__name__', 'asarray', 'backend_version',
> 'cursord', 'cursors', 'division', 'draw_if_interactive', 'enumerate',
> 'error_msg_tkpaint', 'is_string_like', 'math', 'matplotlib',
> 'new_figure_manager', 'os', 'raise_msg_to_str', 'rcParams', 'round',
> 'show', 'sys', 'tkagg', 'verbose', 'windowing']
>
>
>
> I don't see anything obviously wrong though -- I am wondering if my X
> setup is faulty.
>
> Thanks!
>
> Michael Droettboom wrote:
> > It looks like the _tkagg C extension didn't build correctly -- it
> > really should have a tkinit method.
> >
> > Can you please try the following and send me the output (inside the
> > Python interpreter)...
> >
> > >>> from matplotlib.backends import _tkagg
> > >>> _tkagg.__file__
> > >>> dir(_tkagg)
> >
> > Thanks!
> >
> > Mike
> >
> > fiacre wrote:
> >> I'm running Idle via X forwarding to my Windows desktop (running
> >> Cygwin).
> >>
> >> I've installed tcl/tk and python with Tkinter as a backend.
> >>
> >> When I call pylab.show(), I always get the error :
> >> >>> pylab.show()
> >>
> >> Exception in Tkinter callback
> >> Traceback (most recent call last):
> >> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
> >> return self.func(*args)
> >> File
> >> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
> >> line 151, in resize
> >> self.show()
> >> File
> >> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
> >> line 155, in draw
> >> tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
> >> File
> >> "/usr/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", line
> >> 14, in blit
> >> _tkagg.tkinit(id(tk), 0)
> >> AttributeError: 'module' object has no attribute 'tkinit'
> >>
> >>
> >> And an empty matplotlib window opens on my desktop.
> >>
> >>
> >> Should I try gtk as a backend???
> >>
> >> TIA
> >>
> >> -- Andrew
> >>
> >> ------------------------------------------------------------------------
> >>-
> >>
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Staff Scientist
Cornell High Energy Synchrotron Source
Cornell University
275 Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dar...@co...
office: (607) 255-3819
fax: (607) 255-9001
http://www.chess.cornell.edu

I agree -- I don't believe it built correctly either ...
Python 2.5.1 (r251:54863, Mar 20 2008, 04:03:41)
[GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from matplotlib.backends import _tkagg
 >>> _tkagg.__file__
'/usr/lib/python2.5/site-packages/matplotlib/backends/_tkagg.pyc'
 >>> dir(_tkagg)
['AxisMenu', 'Figure', 'FigureCanvasAgg', 'FigureCanvasBase', 
'FigureCanvasTkAgg', 'FigureManager', 'FigureManagerBase', 
'FigureManagerTkAgg', 'FileDialog', 'Gcf', 'GraphicsContextBase', 
'NavigationToolbar', 'NavigationToolbar2', 'NavigationToolbar2TkAgg', 
'PIXELS_PER_INCH', 'RendererBase', 'SubplotTool', 'Tk', '__builtins__', 
'__doc__', '__file__', '__name__', 'asarray', 'backend_version', 
'cursord', 'cursors', 'division', 'draw_if_interactive', 'enumerate', 
'error_msg_tkpaint', 'is_string_like', 'math', 'matplotlib', 
'new_figure_manager', 'os', 'raise_msg_to_str', 'rcParams', 'round', 
'show', 'sys', 'tkagg', 'verbose', 'windowing']
 >>>
I don't see anything obviously wrong though -- I am wondering if my X 
setup is faulty.
Thanks!
Michael Droettboom wrote:
> It looks like the _tkagg C extension didn't build correctly -- it 
> really should have a tkinit method.
>
> Can you please try the following and send me the output (inside the 
> Python interpreter)...
>
> >>> from matplotlib.backends import _tkagg
> >>> _tkagg.__file__
> >>> dir(_tkagg)
>
> Thanks!
>
> Mike
>
> fiacre wrote:
>> I'm running Idle via X forwarding to my Windows desktop (running 
>> Cygwin).
>>
>> I've installed tcl/tk and python with Tkinter as a backend.
>>
>> When I call pylab.show(), I always get the error :
>>
>> >>> pylab.show()
>> Exception in Tkinter callback
>> Traceback (most recent call last):
>> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
>> return self.func(*args)
>> File 
>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
>> line 151, in resize
>> self.show()
>> File 
>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
>> line 155, in draw
>> tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
>> File 
>> "/usr/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", line 
>> 14, in blit
>> _tkagg.tkinit(id(tk), 0)
>> AttributeError: 'module' object has no attribute 'tkinit'
>>
>>
>> And an empty matplotlib window opens on my desktop.
>>
>>
>> Should I try gtk as a backend???
>>
>> TIA
>>
>> -- Andrew
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>

It looks like the _tkagg C extension didn't build correctly -- it really 
should have a tkinit method.
Can you please try the following and send me the output (inside the 
Python interpreter)...
 >>> from matplotlib.backends import _tkagg
 >>> _tkagg.__file__
 >>> dir(_tkagg)
Thanks!
Mike
fiacre wrote:
> I'm running Idle via X forwarding to my Windows desktop (running Cygwin).
>
> I've installed tcl/tk and python with Tkinter as a backend.
>
> When I call pylab.show(), I always get the error :
>
> >>> pylab.show()
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__
> return self.func(*args)
> File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
> line 151, in resize
> self.show()
> File 
> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py", 
> line 155, in draw
> tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
> File "/usr/lib/python2.5/site-packages/matplotlib/backends/tkagg.py", 
> line 14, in blit
> _tkagg.tkinit(id(tk), 0)
> AttributeError: 'module' object has no attribute 'tkinit'
>
>
> And an empty matplotlib window opens on my desktop.
>
>
> Should I try gtk as a backend???
>
> TIA
>
> -- Andrew
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA