RE: SCXML Algorithm fails for test 579

Gavin,
 If you would  try the change below (to the top-level 'else' in addDescendantStatesToEnter) and let me know what happens, that would be useful.  

- Jim

-----Original Message-----
From: Gavin Kistner [mailto:phrogz@me.com] 
Sent: Sunday, June 29, 2014 10:47 AM
To: Jim Barnett
Cc: www-voice@w3.org
Subject: Re: SCXML Algorithm fails for test 579

If you have algorithmic suggestions you'd like to change, I'm now at a place where I can easily modify the runtime and re-run the tests.

On Jun 29, 2014, at 8:17 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:
> 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:54:15 UTC