adding ability to stop statechart from within the statechart

doc/reading_diagrams.rst

@@ -1337,18 +1337,22 @@ of the details of our HSM oven:
     :target: _static/composite_state_3.pdf
     :align: center
 
-There is a good chance that I am breaking the UML standard by drawing the above
-diagram the way I did.  I'm hiding the door_closed state, yet I'm showing part
-of it's design.  I'm showing an arrow going into the door_closed state, and
-showing it land on a deep history icon.  So, am I hiding the state or not?
-Well, I'm doing both.  I'm trying to explain the gist of the hidden part of the
-design: to go back to the previous sub-state of the door_closed part of the
-statechart, when the door is opened after the over was in a door_open state.
-I'm trying to show this history-behavior is happening without going into the
-details of what substates exist within the door_closed state.
-
-When you sketch your diagrams without adhering to a ridged set of drawing rules,
-you can make decisions like this.
+I have hidden the majority of the door_closed state in the decomposition hiding
+state icon.  When you see this icon, you know that some details have been hidden
+to make the diagram fit on a page.  But there is a good chance that I am
+breaking the UML standard by drawing the above diagram the way I did.  I'm
+hiding the door_closed state, yet I'm showing part of it's design.  I'm showing
+an arrow going into the door_closed state, and showing it land on a deep history
+icon.  So, am I hiding the state or not?  Well, I'm doing both.  I'm trying to
+explain the gist of the hidden part of the design: to go back to the previous
+sub-state of the door_closed part of the statechart, when the door is opened
+after the over was in a door_open state.  I'm trying to show this
+history-behavior is happening without going into the details of what substates
+exist within the door_closed state.
+
+When you sketch your diagrams without adhering to a rigid set of drawing rules,
+you can make decisions like this.  The diagrams act as sketches rather than a
+programming language.
 
 .. _reading_diagrams-deep-history-dot:
 
@@ -1362,6 +1366,9 @@ can use the deep history pseudostate, it's a circle enclosing a H*:
     :target: _static/TransitionToHistoryStatePattern.pdf
     :align: center
 
+The :ref:`transition to history <patterns-transition-to-history>` section of the
+patterns part of this document goes into the details about how to implement this in code.
+
 .. _reading_diagrams-if-structures:
 
 If-Else Structures

docs/_sources/reading_diagrams.rst.txt

@@ -1337,18 +1337,22 @@ of the details of our HSM oven:
     :target: _static/composite_state_3.pdf
     :align: center
 
-There is a good chance that I am breaking the UML standard by drawing the above
-diagram the way I did.  I'm hiding the door_closed state, yet I'm showing part
-of it's design.  I'm showing an arrow going into the door_closed state, and
-showing it land on a deep history icon.  So, am I hiding the state or not?
-Well, I'm doing both.  I'm trying to explain the gist of the hidden part of the
-design: to go back to the previous sub-state of the door_closed part of the
-statechart, when the door is opened after the over was in a door_open state.
-I'm trying to show this history-behavior is happening without going into the
-details of what substates exist within the door_closed state.
-
-When you sketch your diagrams without adhering to a ridged set of drawing rules,
-you can make decisions like this.
+I have hidden the majority of the door_closed state in the decomposition hiding
+state icon.  When you see this icon, you know that some details have been hidden
+to make the diagram fit on a page.  But there is a good chance that I am
+breaking the UML standard by drawing the above diagram the way I did.  I'm
+hiding the door_closed state, yet I'm showing part of it's design.  I'm showing
+an arrow going into the door_closed state, and showing it land on a deep history
+icon.  So, am I hiding the state or not?  Well, I'm doing both.  I'm trying to
+explain the gist of the hidden part of the design: to go back to the previous
+sub-state of the door_closed part of the statechart, when the door is opened
+after the over was in a door_open state.  I'm trying to show this
+history-behavior is happening without going into the details of what substates
+exist within the door_closed state.
+
+When you sketch your diagrams without adhering to a rigid set of drawing rules,
+you can make decisions like this.  The diagrams act as sketches rather than a
+programming language.
 
 .. _reading_diagrams-deep-history-dot:
 
@@ -1362,6 +1366,9 @@ can use the deep history pseudostate, it's a circle enclosing a H*:
     :target: _static/TransitionToHistoryStatePattern.pdf
     :align: center
 
+The :ref:`transition to history <patterns-transition-to-history>` section of the
+patterns part of this document goes into the details about how to implement this in code.
+
 .. _reading_diagrams-if-structures:
 
 If-Else Structures

docs/reading_diagrams.html

@@ -1187,17 +1187,21 @@ <h1>Diagrams<a class="headerlink" href="#diagrams" title="Permalink to this head
 of the details of our HSM oven:</p>
 <a class="reference external image-reference" href="_static/composite_state_3.pdf"><div align="center" class="align-center"><img alt="_images/composite_state_3.svg" src="_images/composite_state_3.svg" /></div>
 </a>
-<p>There is a good chance that I am breaking the UML standard by drawing the above
-diagram the way I did.  I’m hiding the door_closed state, yet I’m showing part
-of it’s design.  I’m showing an arrow going into the door_closed state, and
-showing it land on a deep history icon.  So, am I hiding the state or not?
-Well, I’m doing both.  I’m trying to explain the gist of the hidden part of the
-design: to go back to the previous sub-state of the door_closed part of the
-statechart, when the door is opened after the over was in a door_open state.
-I’m trying to show this history-behavior is happening without going into the
-details of what substates exist within the door_closed state.</p>
-<p>When you sketch your diagrams without adhering to a ridged set of drawing rules,
-you can make decisions like this.</p>
+<p>I have hidden the majority of the door_closed state in the decomposition hiding
+state icon.  When you see this icon, you know that some details have been hidden
+to make the diagram fit on a page.  But there is a good chance that I am
+breaking the UML standard by drawing the above diagram the way I did.  I’m
+hiding the door_closed state, yet I’m showing part of it’s design.  I’m showing
+an arrow going into the door_closed state, and showing it land on a deep history
+icon.  So, am I hiding the state or not?  Well, I’m doing both.  I’m trying to
+explain the gist of the hidden part of the design: to go back to the previous
+sub-state of the door_closed part of the statechart, when the door is opened
+after the over was in a door_open state.  I’m trying to show this
+history-behavior is happening without going into the details of what substates
+exist within the door_closed state.</p>
+<p>When you sketch your diagrams without adhering to a rigid set of drawing rules,
+you can make decisions like this.  The diagrams act as sketches rather than a
+programming language.</p>
 </div>
 <div class="section" id="deep-history-icon">
 <span id="reading-diagrams-deep-history-dot"></span><h3>Deep History Icon<a class="headerlink" href="#deep-history-icon" title="Permalink to this headline">¶</a></h3>
@@ -1206,6 +1210,8 @@ <h1>Diagrams<a class="headerlink" href="#diagrams" title="Permalink to this head
 can use the deep history pseudostate, it’s a circle enclosing a H*:</p>
 <a class="reference external image-reference" href="_static/TransitionToHistoryStatePattern.pdf"><div align="center" class="align-center"><img alt="_images/TransitionToHistoryStatePattern.svg" src="_images/TransitionToHistoryStatePattern.svg" /></div>
 </a>
+<p>The <a class="reference internal" href="patterns.html#patterns-transition-to-history"><span class="std std-ref">transition to history</span></a> section of the
+patterns part of this document goes into the details about how to implement this in code.</p>
 </div>
 <div class="section" id="if-else-structures">
 <span id="reading-diagrams-if-structures"></span><h3>If-Else Structures<a class="headerlink" href="#if-else-structures" title="Permalink to this headline">¶</a></h3>

examples/terminate.py

@@ -0,0 +1,24 @@
+import time
+from miros import spy_on
+from miros import ActiveObject
+from miros import signals, Event, return_status
+
+@spy_on
+def some_state(chart, e):
+  status = return_status.UNHANDLED
+  if(e.signal == signals.Destroy_This_Chart):
+    chart.stop()
+    status = return_status.HANDLED
+  else:
+    chart.temp.fun = chart.top
+    status = return_status.SUPER
+  return status
+
+if __name__ == "__main__":
+  ao = ActiveObject('some_state')
+  ao.live_trace = True
+  ao.start_at(some_state)
+  time.sleep(2)
+  ao.post_fifo(Event(signal=signals.Destroy_This_Chart))
+  time.sleep(200)
+

miros/activeobject.py

@@ -665,7 +665,14 @@ def stop(self):
     # post an item to wake up the task so it can see it's event has been cleared
     # this will cause it to exit its forever-loop and exit
     self.queue.append(HsmEvent(signal=signals.stop_active_object))
-    self.thread.join()
+    try:
+      # If stop is being called outside of this active object, wait for this
+      # thread to stop
+      self.thread.join()
+    except RuntimeError:
+      # If stop is being called from within the active object thread, we can not
+      # join our own thread, so proceed with the next steps
+      pass
 
     # kill threads which were started by post_fifo or post_lifo single-shots or
     # multi-shots

plan/release_notes.wiki

@@ -0,0 +1,3 @@
+Allowing stop to be called within ActiveObject or Factory
+
+* the stop method can now be called within an ActiveObject or a Factory.

setup.py

@@ -24,7 +24,7 @@
     py_modules=['miros'],
 
     # https://packaging.python.org/en/latest/single_source_version.html
-    version='4.1.00',
+    version='4.1.1',
 
     description='A statechart library for Python',
     long_description=long_description,

test/active_object_start_stop_test.py

@@ -1,9 +1,11 @@
 import time
 import pytest
 from miros import Event
+from miros import spy_on
 from miros import signals
 from miros import Factory
 from collections import deque
+from miros import ActiveObject
 from miros import return_status
 from collections import namedtuple
 
@@ -121,6 +123,27 @@ def test_that_stopping_the_fabric_stops_the_tasks():
   time.sleep(0.1)
   assert(ssc.thread.is_alive() == False)
 
+@spy_on
+def some_state(chart, e):
+  status = return_status.UNHANDLED
+  if(e.signal == signals.Destroy_This_Chart):
+    chart.stop()
+    status = return_status.HANDLED
+  else:
+    chart.temp.fun = chart.top
+    status = return_status.SUPER
+  return status
+
+@pytest.mark.stop
+def test_that_stop_works_within_an_active_object():
+  ao = ActiveObject('some_state')
+  ao.start_at(some_state)
+  time.sleep(0.1)
+  assert(ao.thread.is_alive() == True)
+  ao.post_fifo(Event(signal=signals.Destroy_This_Chart))
+  time.sleep(0.1)
+  assert(ao.thread.is_alive() == False)
+
 if __name__ == "__main__":
   print("hey")
   ssc = StartStopChart('whatever')