|
From: Justin L. <jl...@gm...> - 2013-07-17 15:13:57
|
Hi all,
I'm using a timer object to interact with the MPL event loop on my OS X
laptop. However, it seems to be missing a few key methods that are
making using it a little difficult. In particular, I can't find a way to
stop the timer from sending events:
$ ipython --pylab
In [1]: def fun():
...: for i in range(5):
...: print "We're having fun!"; yield
...: for i in range(5):
...: print "Too much fun..."; yield
...: while True:
...: print "Stop the fun! No more!"; yield
In [2]: f = fun().next
In [3]: fig = plt.figure()
In [4]: t = fig.canvas.new_timer()
In [5]: t.add_callback(f)
In [6]: t.start()
In [7]: t.stop()
In [8]: del t # It's all over now...
It looks like the stop method may never have been implemented:
In [3]: t.stop??
Type: instancemethod
String Form:<bound method TimerMac.stop of Timer object 0x106ba33b0
wrapping CFRunLoopTimerRef 0x0>
File: /usr/local/lib/python2.7/site-packages/matplotlib/backend_bases.py
Definition: t.stop(self)
Source:
def stop(self):
'''
Stop the timer.
'''
self._timer_stop()
In [4]: t._timer_stop??
Type: instancemethod
String Form:<bound method TimerMac._timer_stop of Timer object
0x106ba33b0 wrapping CFRunLoopTimerRef 0x0>
File: /usr/local/lib/python2.7/site-packages/matplotlib/backend_bases.py
Definition: t._timer_stop(self)
Source:
def _timer_stop(self):
pass
I'm able to remove the callback function from the timer's callback list,
but I suspect that won't stop the events from being triggered. But I'd
really prefer to completely stop the timer events, since in my
application I may end up going through many timers.
Is this the expected behavior? Is there an easy fix I'm overlooking?
Version info:
In [3]: sys.version
Out[3]: '2.7.3 (default, Feb 19 2013, 18:00:31) \n[GCC 4.2.1
Compatible Apple LLVM 4.2 (clang-425.0.24)]'
In [4]: mpl.__version__
Out[4]: '1.2.0'
Thanks,
Justin
|
|
From: Michiel de H. <mjl...@ya...> - 2013-07-18 04:54:36
|
Hi Justin,
The .stop() method was indeed never implemented for Timer objects in the MacOSX backend.
I am not sure if a .stop() method is really needed, because deleting the timer has the same effect as stopping the timer.
Is there some reason you prefer
>>> t.stop()
instead of
>>> del t
?
Best,
-Michiel
________________________________
From: Justin Lazear <jl...@gm...>
To: Mat...@li...
Sent: Thursday, July 18, 2013 12:13 AM
Subject: [Matplotlib-users] timer objects in macosx backend
Hi all,
I'm using a timer object to interact with the MPL event loop on my
OS X laptop. However, it seems to be missing a few key methods that
are making using it a little difficult. In particular, I can't find
a way to stop the timer from sending events:
$ ipython --pylab
In [1]: def fun():
> ...: for i in range(5):
> ...: print "We're having fun!"; yield
> ...: for i in range(5):
> ...: print "Too much fun..."; yield
> ...: while True:
> ...: print "Stop the fun! No more!"; yield
>
>In [2]: f = fun().next
>
>In [3]: fig = plt.figure()
>
>In [4]: t = fig.canvas.new_timer()
>
>In [5]: t.add_callback(f)
>
>In [6]: t.start()
>
>In [7]: t.stop()
>
>In [8]: del t # It's all over now...
>
It looks like the stop method may never have been implemented:
In [3]: t.stop??
>Type: instancemethod
>String Form:<bound method TimerMac.stop of Timer object
0x106ba33b0 wrapping CFRunLoopTimerRef 0x0>
>File:
/usr/local/lib/python2.7/site-packages/matplotlib/backend_bases.py
>Definition: t.stop(self)
>Source:
> def stop(self):
> '''
> Stop the timer.
> '''
> self._timer_stop()
>
>In [4]: t._timer_stop??
>Type: instancemethod
>String Form:<bound method TimerMac._timer_stop of Timer object
0x106ba33b0 wrapping CFRunLoopTimerRef 0x0>
>File:
/usr/local/lib/python2.7/site-packages/matplotlib/backend_bases.py
>Definition: t._timer_stop(self)
>Source:
> def _timer_stop(self):
> pass
>
I'm able to remove the callback function from the timer's callback
list, but I suspect that won't stop the events from being triggered.
But I'd really prefer to completely stop the timer events, since in
my application I may end up going through many timers.
Is this the expected behavior? Is there an easy fix I'm overlooking?
Version info:
In [3]: sys.version
>Out[3]: '2.7.3 (default, Feb 19 2013, 18:00:31) \n[GCC 4.2.1
Compatible Apple LLVM 4.2 (clang-425.0.24)]'
>
>In [4]: mpl.__version__
>Out[4]: '1.2.0'
>
Thanks,
Justin
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
|
From: Justin L. <jl...@gm...> - 2013-07-18 13:57:05
|
Hi Michiel, On my system, deleting the timer has no effect and the timer continues to send events. The __del__ method seems to call the same unimplemented _timer_stop method. Regardless, something else has a reference to the timer (MPL event loop maybe?) and __del__ is not being called once the timer has been started. It's not clear to me what should be stopping the timer in that case. Does del t stop the timer on your system? If so, could we hunt down what is happening after you delete the name t that is causing the timer to stop? I would personally prefer an explicit .stop() method, since I would prefer not to rely on the garbage collector's behavior being consistent (hard to make sure nothing else is holding a reference to timer) when there is a very well-defined function that does what I want. Thanks, Justin On 7/18/13 12:54 AM, Michiel de Hoon wrote: > Hi Justin, > > The .stop() method was indeed never implemented for Timer objects in > the MacOSX backend. > I am not sure if a .stop() method is really needed, because deleting > the timer has the same effect as stopping the timer. > Is there some reason you prefer > >>> t.stop() > instead of > >>> del t > ? > > Best, > -Michiel > > > ------------------------------------------------------------------------ > *From:* Justin Lazear <jl...@gm...> > *To:* Mat...@li... > *Sent:* Thursday, July 18, 2013 12:13 AM > *Subject:* [Matplotlib-users] timer objects in macosx backend > > Hi all, > > I'm using a timer object to interact with the MPL event loop on my OS > X laptop. However, it seems to be missing a few key methods that are > making using it a little difficult. In particular, I can't find a way > to stop the timer from sending events: > > $ ipython --pylab > > In [1]: def fun(): > ...: for i in range(5): > ...: print "We're having fun!"; yield > ...: for i in range(5): > ...: print "Too much fun..."; yield > ...: while True: > ...: print "Stop the fun! No more!"; yield > > In [2]: f = fun().next > > In [3]: fig = plt.figure() > > In [4]: t = fig.canvas.new_timer() > > In [5]: t.add_callback(f) > > In [6]: t.start() > > In [7]: t.stop() > > In [8]: del t # It's all over now... > > > It looks like the stop method may never have been implemented: > > In [3]: t.stop?? > Type: instancemethod > String Form:<bound method TimerMac.stop of Timer object > 0x106ba33b0 wrapping CFRunLoopTimerRef 0x0> > File: > /usr/local/lib/python2.7/site-packages/matplotlib/backend_bases.py > Definition: t.stop(self) > Source: > def stop(self): > ''' > Stop the timer. > ''' > self._timer_stop() > > In [4]: t._timer_stop?? > Type: instancemethod > String Form:<bound method TimerMac._timer_stop of Timer object > 0x106ba33b0 wrapping CFRunLoopTimerRef 0x0> > File: > /usr/local/lib/python2.7/site-packages/matplotlib/backend_bases.py > Definition: t._timer_stop(self) > Source: > def _timer_stop(self): > pass > > > I'm able to remove the callback function from the timer's callback > list, but I suspect that won't stop the events from being triggered. > But I'd really prefer to completely stop the timer events, since in my > application I may end up going through many timers. > > Is this the expected behavior? Is there an easy fix I'm overlooking? > > Version info: > > In [3]: sys.version > Out[3]: '2.7.3 (default, Feb 19 2013, 18:00:31) \n[GCC 4.2.1 > Compatible Apple LLVM 4.2 (clang-425.0.24)]' > > In [4]: mpl.__version__ > Out[4]: '1.2.0' > > > Thanks, > Justin > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > |
|
From: Brendan B. <bre...@br...> - 2013-07-18 19:10:30
|
On 2013-07-18 06:56, Justin Lazear wrote:> Hi Michiel,
>
> On my system, deleting the timer has no effect and the timer continues
> to send events. The __del__ method seems to call the same unimplemented
> _timer_stop method. Regardless, something else has a reference to the
> timer (MPL event loop maybe?) and __del__ is not being called once the
> timer has been started. It's not clear to me what should be
stopping the
> timer in that case.
>
> Does del t stop the timer on your system? If so, could we hunt down
what
> is happening after you delete the name t that is causing the timer
to stop?
>
> I would personally prefer an explicit .stop() method, since I would
> prefer not to rely on the garbage collector's behavior being consistent
> (hard to make sure nothing else is holding a reference to timer) when
> there is a very well-defined function that does what I want.
Relying on "del t" can't be the right solution, since like you note,
it only deletes the name, not the object. If you create multiple
references to a timer and only del some of them, e.g.:
t = fig.canvas.new_timer()
x = t
del t
Then the object's __del__ will definitely not be called yet. It makes
sense to have a way to stop the timer directly, regardless of how many
names are pointing to it.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
|
|
From: Michiel de H. <mjl...@ya...> - 2013-07-19 01:44:09
|
Hi Brendan, Justin, Thanks for your reply. I agree then that a .stop() method is needed. This is not very difficult; I'll try and implement it over the weekend. Best, -Michiel. ________________________________ From: Brendan Barnwell <bre...@br...> To: mat...@li... Sent: Friday, July 19, 2013 3:54 AM Subject: Re: [Matplotlib-users] timer objects in macosx backend On 2013-07-18 06:56, Justin Lazear wrote:> Hi Michiel, > > On my system, deleting the timer has no effect and the timer continues > to send events. The __del__ method seems to call the same unimplemented > _timer_stop method. Regardless, something else has a reference to the > timer (MPL event loop maybe?) and __del__ is not being called once the > timer has been started. It's not clear to me what should be stopping the > timer in that case. > > Does del t stop the timer on your system? If so, could we hunt down what > is happening after you delete the name t that is causing the timer to stop? > > I would personally prefer an explicit .stop() method, since I would > prefer not to rely on the garbage collector's behavior being consistent > (hard to make sure nothing else is holding a reference to timer) when > there is a very well-defined function that does what I want. Relying on "del t" can't be the right solution, since like you note, it only deletes the name, not the object. If you create multiple references to a timer and only del some of them, e.g.: t = fig.canvas.new_timer() x = t del t Then the object's __del__ will definitely not be called yet. It makes sense to have a way to stop the timer directly, regardless of how many names are pointing to it. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-users mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
|
From: Michiel de H. <mjl...@ya...> - 2013-07-21 05:04:22
|
See pull request 2233: https://github.com/matplotlib/matplotlib/pull/2233 This pull request adds a .stop() method to timers in the MacOSX backend. Best, -Michiel. ________________________________ From: Michiel de Hoon <mjl...@ya...> To: Brendan Barnwell <bre...@br...>; "mat...@li..." <mat...@li...> Sent: Friday, July 19, 2013 10:44 AM Subject: Re: [Matplotlib-users] timer objects in macosx backend Hi Brendan, Justin, Thanks for your reply. I agree then that a .stop() method is needed. This is not very difficult; I'll try and implement it over the weekend. Best, -Michiel. ________________________________ From: Brendan Barnwell <bre...@br...> To: mat...@li... Sent: Friday, July 19, 2013 3:54 AM Subject: Re: [Matplotlib-users] timer objects in macosx backend On 2013-07-18 06:56, Justin Lazear wrote:> Hi Michiel, > > On my system, deleting the timer has no effect and the timer continues > to send events. The __del__ method seems to call the same unimplemented > _timer_stop method. Regardless, something else has a reference to the > timer (MPL event loop maybe?) and __del__ is not being called once the > timer has been started. It's not clear to me what should be stopping the > timer in that case. > > Does del t stop the timer on your system? If so, could we hunt down what > is happening after you delete the name t that is causing the timer to stop? > > I would personally prefer an explicit .stop() method, since I would > prefer not to rely on the garbage collector's behavior being consistent > (hard to make sure nothing else is holding a reference to timer) when > there is a very well-defined function that does what I want. Relying on "del t" can't be the right solution, since like you note, it only deletes the name, not the object. If you create multiple references to a timer and only del some of them, e.g.: t = fig.canvas.new_timer() x = t del t Then the object's __del__ will definitely not be called yet. It makes sense to have a way to stop the timer directly, regardless of how many names are pointing to it. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-users mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-users mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users |