RE: Bug with deep and shallow history in pseudo-code

No, but by the time this is called, the history state would have been de-referenced, and the actual history values would be on the statesToEnter list.


-          Jim

From: chris nuernberger [mailto:cnuernber@gmail.com]
Sent: Saturday, February 09, 2013 5:46 PM
To: Jim Barnett
Cc: Stefan Radomski; www-voice@w3.org (www-voice@w3.org)
Subject: Re: Bug with deep and shallow history in pseudo-code

getChildStates would not return a history state, would it?

Chris

On Sat, Feb 9, 2013 at 3:22 PM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
Stefan,
  This clause in enterStates is supposed to catch that case:

                    statesToEnter.add(anc)
                    if isParallelState(anc):
                        for child in getChildStates(anc):
                            if not statesToEnter.some(lambda s: isDescendant(s,child)):
                                addStatesToEnter(child,statesToEnter,statesForDefaultEntry)

but it may be missing something.  I need to look at enterStates and addStatesToEnter more closely.  At the very least, they need to be reorganized for clarity.

= Jim

-----Original Message-----
From: Stefan Radomski [mailto:radomski@tk.informatik.tu-darmstadt.de<mailto:radomski@tk.informatik.tu-darmstadt.de>]
Sent: Saturday, February 09, 2013 1:04 PM
To: www-voice@w3.org<mailto:www-voice@w3.org> (www-voice@w3.org<mailto:www-voice@w3.org>)
Subject: Bug with deep and shallow history in pseudo-code

Hi again,

the SCXML document at [1] will put my interpreter in an illegal state configuration. I am sure that there is a more concise example that would accomplish the same, but it is part of Jacob's test framework.

Initial:
  Enabled transitions: {root -> a}
  Stable initial configuration: {a}

t1 arrives:
  Enabled transitions: {a -> p}
  Stable configuration: {p, b, b1, b1.1, c, c1, c1.1}

t2 arrives:
  Enabled transitions: {b1.1 -> b1.2, c1.1 -> c1.2}
  Stable configuration: {p, b, b1, c, c1, b1.2, c1.2}

t3 arrives:
  Enabled transitions: {b1.2 -> b2, c1.2 -> c2}
  Stable configuration: {p, b, c, b2, b2.1, c2, c2.1}

t4 arrives:
  Enabled transitions: {b2.1 -> b2.2, c2.1 -> c2.2}
  Stable configuration: {p, b, c, b2, c2, b2.2, c2.2}

When t5 arrives, we exit everything and enter "a" again, thus we have to save three histories:
  hp: {b2.2, c2.2}
  hb: {b2.2}
  hc: {c2}
  Stable configuration: {a}

t6 will transition into "p" again and bring the interpreter into an illegal configuration:
  addStatesToEnter will realize that "p" is parallel an attempt to enter all its children
    Entering hp will enter {b2.2, c2.2} as its history
    As "p" is parallel, we will enter "c" as well, as it is compound, we will enter its initial shallow history "hc", adding "c2"
      "c2" is compound and its initial state "c2.1" will be entered.

-> we now have "c2.2" and "c2.1" in the configuration which is illegal.

Who is supposed to prevent "c2" from entering its initial state? We already entered "c2.2" per deep history from "hp" and now the shallow history from "hc" wants to enter "c2" and ultimately its initial state "c2.1" leading to an invalid configuration.

Best regards
Stefan

[1] https://github.com/jbeard4/scxml-test-framework/blob/master/test/history/history4.scxml







--
A foolish consistency is the hobgoblin of little minds - Emerson