target-less transitions

19 views
Skip to first unread message

Matt O

unread,
Jul 26, 2012, 4:06:11 AM7/26/12
to scio...@googlegroups.com
Hi, Jacob,

I have a state chart which contains a target-less transition. Something like:

<scxml
    xmlns="http://www.w3.org/2005/07/scxml"
    version="1.0"
    profile="ecmascript"
    initial="S1">
  <state id="S1">
    <onentry>
      <log expr="'entering S1'"/>
    </onentry>
    <transition event="E1" target="fin"/>
    <transition event="E2">
      <log expr="'Do some work, but do not transition'"/>
    </transition>
  </state>
  <final id="fin">
</scxml>

When I execute this in scion's ('shell' build (aka non-browser, non-node)), I get the following error:

"targetIds has no properties"

Also, when I attempt to diagnose by passing in the following options when constructing the interpreter:

  var opts= {log: function(msg) { print(msg); },
    printTrace: truen
  }
  var interp = new scxml.SimpleInterpreter(model, opts);

I get the following error:

"this._log is not a function"

Thanks.

Matt

Jacob Beard

unread,
Jul 26, 2012, 9:15:02 AM7/26/12
to scio...@googlegroups.com
Hi Matt,

Which version of SCION are you using? I've recently done some work in master which could affect this.

Please let me know. Thanks,

Jake

Jacob Beard

unread,
Jul 26, 2012, 10:41:18 AM7/26/12
to scio...@googlegroups.com
Hi Matt,

I've actually just released SCION v0.0.8. I would recommend updating, and we can go from there.

Thanks,

Jake

MattO

unread,
Jul 26, 2012, 3:03:00 PM7/26/12
to scio...@googlegroups.com
Hi, Jacob,

I'm using pySCION (integrating with SpiderMonkey/C++ 1.7).

Looks like my onTransition callback assumed that the targetIds
parameter would always be defined.

I've modified my code, but would you be willing to have the API always
return at least an empty array? Alternatively, can you enhance the
docs on this callback?

Aside: with v0.0.8 I see you've removed printTrace as an option.
Seemed useful to flip this on (to see what's going on) via the driver
rather than having to modify the scion code.

When it's enabled the code calls platform.log. Also noticed a few
other calls through platform. Is there a prescribed way for an
interpreter container to plug in a 'platform'?

Matt

Jacob Beard

unread,
Jul 26, 2012, 3:47:51 PM7/26/12
to scio...@googlegroups.com
Hi Matt,

On Thu, Jul 26, 2012 at 3:03 PM, MattO <matt....@gmail.com> wrote:
Hi, Jacob,

I'm using pySCION (integrating with SpiderMonkey/C++ 1.7).

I rev'd pySCION to use SCION 0.0.8, and tagged it, so this should provide a straightforward path to upgrade.


Looks like my onTransition callback assumed that the targetIds
parameter would always be defined.

I've modified my code, but would you be willing to have the API always
return at least an empty array? Alternatively, can you enhance the
docs on this callback?

I'll update the docs.
 

Aside: with v0.0.8 I see you've removed printTrace as an option.
Seemed useful to flip this on (to see what's going on) via the driver
rather than having to modify the scion code.

I took it out while I was investigating the Google Closure compiler, as with a simple boolean constant, the Closure Compiler is able to strip out the trace as dead code. The trace is mostly meant to be used for debugging the interpreter during development, and furthermore, the code that it traces has been stable for a long time, so it's actually been months since I've needed to turn it on. For these reasons, I'm not sure if it still makes sense to expose it as a developer-facing option. A more developer-friendly approach would probably be to attach listeners using registerListener, and to add logging to the SCXML files using scxml's <log> statement. 
 

When it's enabled the code calls platform.log. Also noticed a few
other calls through platform. Is there a prescribed way for an
interpreter container to plug in a 'platform'?

This is something I'm planning to add to the next release. This is one of a few features of the SCION interpreter that I'd like to make extensible by developers. Specifically, these are:
* the "platform", which is an adapter which implements a small interface on top of platform-specific APIs for performing things like network and filesystem access, and XML DOM parsing, and gets loaded dynamically at runtime
* custom <send> implementation, as send/@type is meant to be extensible.
* custom <invoke> implementation, as invoke/@type is meant to be extensible
* custom actions tags

I'd like to provide a uniform way of allowing developers to extend these SCION features, and so I'm still considering the best way to expose this. 

If this is something that would be immediately useful to you, let me know, and I'll keep you informed as to when I have something in master that you can develop against.

Jake

MattO

unread,
Jul 26, 2012, 8:07:23 PM7/26/12
to scio...@googlegroups.com
Hi, Jake,

For those of us less familiar with your engine but who would benefit
from more insight into how it's processing a particular machine, it
would be value to provide an API (e.g. attach a listener) to turn up
the noise.

Yes, please keep me informed on your platform extensibility model.

Regards,
Matt
Reply all
Reply to author
Forward
0 new messages