- From: Gavin Kistner <phrogz@me.com>
- Date: Sun, 29 Jun 2014 08:47:16 -0600
- To: Jim Barnett <1jhbarnett@gmail.com>
- Cc: www-voice@w3.org
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:48:03 UTC