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

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 <jlazear@…287…>
To: Matplotlib-users@lists.sourceforge.net
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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 <jlazear@...287...>
*To:* Matplotlib-users@lists.sourceforge.net
*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
Matplotlib-users@lists.sourceforge.net <mailto:Matplotlib-users@lists.sourceforge.net>
matplotlib-users List Signup and Options

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

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 <brenbarn@…1219…>
To: matplotlib-users@lists.sourceforge.net
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
Matplotlib-users@…813…ourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

See pull request 2233:

This pull request adds a .stop() method to timers in the MacOSX backend.

Best,

-Michiel.

···

From: Michiel de Hoon <mjldehoon@…9…>
To: Brendan Barnwell <brenbarn@…1219…>; “matplotlib-users@lists.sourceforge.netmatplotlib-users@lists.sourceforge.net
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 <brenbarn@…1219…>
To: matplotlib-users@lists.sourceforge.net
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
Matplotlib-users@lists.sourceforge.net
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
Matplotlib-users@…1738…net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users