Re: SCXML Algorithm fails for test 579

Sigh, you're right.  The problem is that getEfffectiveTargetStates does 
not check for default history content.  I wonder if the solution is to 
get rid of getEffectiveTargetStates and let addDescendantStatesToEnter 
do the work.  The resulting clause would be:

         statesToEnter.add(state)
         if isCompoundState(state):
             statesForDefaultEntry.add(state)
             for s in state.initial.transition.target:
                 addDescendantStatesToEnter(s,statesToEnter,statesForDefaultEntry, defaultHistoryContent)
                 addAncestorStatesToEnter(s, state, statesToEnter, statesForDefaultEntry, defaultHistoryContent)


But I'll have to think about this some more.  Anyone else have any ideas?

- Jim

On 6/29/2014 12:29 AM, Gavin Kistner wrote:
> # BACKGROUND
> I have implemented the algorithm from the specification as verbatim as I can.
> (If you care to compare, see [1] starting on line 40.)
>
> I currently skip 39 of the 160 required non-manual tests, due to lack of feature support. (No <invoke>, no <send> to external targets, no IO Processors, no <data src=…>.)
>
> I pass 118 of the remaining 121. The one that I’m stuck on right now is test 579 [2], and **I think that the cause is a problem with the algorithm from the spec**.
>
>
> # PROBLEM DETAILS
> The symptom of test 579 failing is that the executable content from the history state’s initial transition is never run, i.e. event3 is never raised.
>
> For the content to be executed, `defaultHistoryStates` must be populated so that it can be executed in `enterStates()`.
>
> It can only get populated if `addDescendantStatesToEnter()` is called with the history element as an argument.
>
> However, that never occurs:
>
> * `addDescendantStatesToEnter()` is passed `s0`,
> * which then calls `getEffectiveTargetStates()` for `sh1` (the history state),
> * which then directly calls `addDescendantStatesToEnter()` with `s01`.
>
> At this point `sh1` has been skipped, and is never revisited.
>
> I have put a full trace of the runtime for this test online at [3]. Perhaps my runtime is flawed and the algorithm is fine. It does not seem that way, though.
>
> I do not currently have a recommendation for changing the algorithm to cover this case. Hopefully one of you will.
>
>
> # TEST CODE COVERAGE OF THE ALGORITHM
> Also, for the curious, I’ve put a code coverage analysis of the runtime up at [4]. The numbers in the first column are the number of times that each line of code is exercised in executing the 118 tests (comprised of 120 test files). A leading line of `****0` indicates that the code is never run, and thus may be in error.
>
> This is only really useful once I execute every test, but it is looking promising so far in terms of overall coverage. There are very few holes, and some of them are directly related to my <invoke> skipping.
>
>
> [1] https://github.com/Phrogz/LXSC/blob/master/lib/runtime.lua
> [2] http://www.w3.org/Voice/2013/scxml-irp/579/test579.txml
> [3] https://gist.github.com/Phrogz/170da0e41632de9771f7
> [4] https://gist.github.com/Phrogz/9e7180b6c37ee0643260

-- 
Jim Barnett
Genesys

Received on Sunday, 29 June 2014 14:18:06 UTC