matplotlib-devel Mailing List for matplotlib

On 10/01/2010 09:40 AM, Friedrich Romstedt wrote:
> There were several question on the user's list in the recent past
> reporting hangs and similar when using TkAgg backend& interactive
> mode.
>
> It is known that Tkinter doesn't play well with threading, as long as
> one isn't done very carefully.
>
> It could be that matplotlib has implemented it in a way not safe for
> Tkinter. This applies if there are Tkinter methods called from
> threads other than those which imported Tkinter.
>
> It results in unpredicatable behaviour with exactly the features
> reported: Hang-ups, blankening, partial hangup of part of the threads.
>
> Is a rewrite of the Tk interactive code necessary?
I don't see any use of the threading module in backend_tkagg.py or 
backend_bases.py. Is that what you are referring to?
Ipython -pylab does use threads (version 0.10), but is intended to avoid 
problems by running all user code in a single separate thread.
Eric
>
> Friedrich

On Fri, Oct 1, 2010 at 5:07 PM, Paul Kienzle <pau...@ni...> wrote:
> Note a small issue on the install of matplotlib-1.0.0 python 2.6 mac
> dmg.
>
> The files in mpl-data/images were not installed with read permissions
> for all.
>
> This resulted in an error that _cidgcf was not a valid attribute in
> FigureManager.
>
> This affected one 10.5 machine but not another --- we have no idea why.
>
> - Paul
>
>
We have noticed this for a little while now, and I think we recently
narrowed down the cause. The difference between computers might have to do
with exactly how it was installed.
Not exactly sure, but it is possible that if it was installed from an
account with admin rights, you get a different behavior than if you install
from an account without admin rights and have to give an admin password.
Was there a difference in setups for the two computers and/or how you
installed matplotlib?
Ben Root

Note a small issue on the install of matplotlib-1.0.0 python 2.6 mac 
dmg.
The files in mpl-data/images were not installed with read permissions 
for all.
This resulted in an error that _cidgcf was not a valid attribute in 
FigureManager.
This affected one 10.5 machine but not another --- we have no idea why.
 - Paul

There were several question on the user's list in the recent past
reporting hangs and similar when using TkAgg backend & interactive
mode.
It is known that Tkinter doesn't play well with threading, as long as
one isn't done very carefully.
It could be that matplotlib has implemented it in a way not safe for
Tkinter. This applies if there are Tkinter methods called from
threads other than those which imported Tkinter.
It results in unpredicatable behaviour with exactly the features
reported: Hang-ups, blankening, partial hangup of part of the threads.
Is a rewrite of the Tk interactive code necessary?
Friedrich

Hey Ryan,
On Fri, Oct 1, 2010 at 6:27 AM, Ryan May <rm...@gm...> wrote:
> On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez <fpe...@gm...> wrote:
>> This manifested itself in some more complex MPL code that had multiple
>> events not working when run inside ipython, but working OK outside of
>> ipython. Fortunately, the small self-contained example demonstrates
>> the problem even with ipython not being in the picture at all (the
>> runs above were from the command line), so I think there is an issue
>> in MPL proper.
>>
>> Sorry that I can't dig deeper into the code right now to look for a fix...
>
> Somewhere in the 1.0 development cycle, Michael modified the callback
> code to take weak references to methods. The purpose was to eliminate
> some "leaks" that were occurring because callback connections to
> objects were keeping them around and the proper disconnects were not
> made (much simpler fix than tracking down every mpl_connect and trying
> to see where do disconnect). What you're seeing in your script is that
> since you're not assigning the Handler object to anything, it's being
> garbage collected. It works for me if I change the second to last line
> to:
>
>  h = Handler(f)
Many thanks for the info, that helps a lot.
I was wondering though, would we still have a leak if strong
references are held in the canvas attribute? The canvas will be
deleted when the figure goes away, so that should properly allow the
callback references to be deleted, without deleting them early
otherwise, no?
In any case, if my logic is flawed (quite likely, since I imagine M.
D. had a good look at this), it might be worth adding a
.. warning::
section about this pattern to the event docs:
http://matplotlib.sourceforge.net/users/event_handling.html
because the problem is subtle and hard to diagnose (I just noticed it
had also been reported recently
http://sourceforge.net/mailarchive/forum.php?thread_name=4C9B7793.5020908%40gmail.com&forum_name=matplotlib-devel).
In any case, thanks again for the help!
Cheers,
f

On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez <fpe...@gm...> wrote:
> This manifested itself in some more complex MPL code that had multiple
> events not working when run inside ipython, but working OK outside of
> ipython. Fortunately, the small self-contained example demonstrates
> the problem even with ipython not being in the picture at all (the
> runs above were from the command line), so I think there is an issue
> in MPL proper.
>
> Sorry that I can't dig deeper into the code right now to look for a fix...
Somewhere in the 1.0 development cycle, Michael modified the callback
code to take weak references to methods. The purpose was to eliminate
some "leaks" that were occurring because callback connections to
objects were keeping them around and the proper disconnects were not
made (much simpler fix than tracking down every mpl_connect and trying
to see where do disconnect). What you're seeing in your script is that
since you're not assigning the Handler object to anything, it's being
garbage collected. It works for me if I change the second to last line
to:
 h = Handler(f)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Howdy,
I spent a while chasing my tail today with some event handling code
until I tried backtracking from SVN matplotlib back to 0.99.1 (the one
in ubuntu 10.04) and the problem went away.
I'm attaching a script that reproduces the problem with a full
description in the docstring, reproduced here for completeness:
This example wires two event handlers that both respond to clicks by printing
event info identically. One is written as a standalone function, the other as
a method of an object.
- when run with MPL 0.99.1.1 (stock in ubuntu 10.04), both fire fine:
amirbar[mplbrush]> python mpleventbug.py
MPL version: 0.99.1.1
MPL: /usr/lib/pymodules/python2.6/matplotlib/__init__.py
/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py:621:
DeprecationWarning: Use the new widget gtk.Tooltip
 self.tooltips = gtk.Tooltips()
C1 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C2 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C1 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C2 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C1 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
C2 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
etc...
- when run with matplotlib r8721, the one that is a method does not fire:
amirbar[mplbrush]> python mpleventbug.py
MPL version: 1.0.0
MPL: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/__init__.pyc
C1 - button=1, x=150, y=170, xdata=24.876982, ydata=0.587719
C1 - button=1, x=169, y=160, xdata=30.071077, ydata=0.543860
C1 - button=1, x=187, y=135, xdata=34.991799, ydata=0.434211
C1 - button=1, x=210, y=120, xdata=41.279388, ydata=0.368421
###
This manifested itself in some more complex MPL code that had multiple
events not working when run inside ipython, but working OK outside of
ipython. Fortunately, the small self-contained example demonstrates
the problem even with ipython not being in the picture at all (the
runs above were from the command line), so I think there is an issue
in MPL proper.
Sorry that I can't dig deeper into the code right now to look for a fix...
Timing note: EPD is planning a release in a few weeks, I don't know
how close MPL is to a bugfix release in the 1.0.x series. I don't
know what version of mpl EPD plans to use, but if event handling is
really broken and a fix is feasible in the time available, it might be
worth pushing it through.
Cheers,
f