Re: [matplotlib-devel] Event handling broken in svn?
On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez 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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Event handling broken in svn?
Hey Ryan, On Fri, Oct 1, 2010 at 6:27 AM, Ryan May wrote: > On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez 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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Is Tkinter-matplotlib using Threads?
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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mac install 1.0.0
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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mac install 1.0.0
On Fri, Oct 1, 2010 at 5:07 PM, Paul Kienzle 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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Is Tkinter-matplotlib using Threads?
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 -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] [PATCH] Discontinuous colormaps are reversed incorrectly
Hi, developers. I stumbled upon this when I noticed that gist_stern_r isn't
the reverse of gist_stern. As the attached script shows, the discontinuity in
red is wrong, and green stays zero instead of ramping. The problem seems to be
that when cm.revcmap() reverses a linear segment map spec (such as {'red':
[(0, 0, 0), (0.5, 1, 1), (1, 1, 1)], ...}), it doesn't swap the second and
third elements of each tuple-the color values facing in each direction. That
makes no difference for continuous colormaps but distorts discontinuous maps
such as gist_stern. I believe that the attached "cm.patch" file fixes the
problem.
The other patch, "_cm.patch", is only aesthetic after the above patch is
applied. It changes an element of the gist_stern colormap spec that should
have been unused but which caused the green channel to stay at zero with the
old revcmap. With the patched revcmap, the changed element should not be used,
but the colormap spec will look like most others with the second and third
elements of the tuple being equal.
import matplotlib as mpl
import matplotlib.pyplot as plt
import matplotlib.cm as mcmap
import numpy as np
def show_cmap_rgb(cmap, axes):
x = np.linspace(0, 1, 256)
rgba = cmap(x)
lines = []
for (idx, color) in enumerate('rgb'):
lines.extend(axes.plot(x, rgba[:, idx], ':', color=color))
axes.set_xlim(0, 1)
axes.set_ylim(-0.1, 1.1)
return lines
fig = plt.figure()
axes_f = fig.add_subplot(2, 1, 1)
show_cmap_rgb(mcmap.gist_stern, axes_f)
axes_f.set_title('Forward')
axes_r = fig.add_subplot(2, 1, 2)
show_cmap_rgb(mcmap.gist_stern_r, axes_r)
axes_r.invert_xaxis()
axes_r.set_title('Reversed')
cm.patch
Description: Binary data
_cm.patch
Description: Binary data
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
