support for send/@target='#_internal'?

[Matt O]

Hi, Jacob,

I was wondering if you've considered / would be willing to add support for <send> where target|targetexpr is set to the special '#_internal'.

I'm looking for a way to send a dynamically constructed event name, so unfortunately, that disqualfiies use of <raise>.

Also, I'm embedding scion in an environment that does not include setTimeout functionality. I'm not sure if that will be another stumbling block given what I see in SimpleInterpreter.prototype._send, or perhaps I'm misreading the code.

Thanks.

Matt

[Jacob Beard]

Done. Change is in master.

I think you'll need to define a custom send function. You can find documentation on how to do this here: https://github.com/jbeard4/SCION/wiki/Action-Tag-Scripting-API

If you have any questions, please don't hesitate to ask. Best,

Jake

[MattO]

Thanks for the quick turnaround, Jacob.

Would you remove the rogue console.log from lib/core/util/code-gen.js:131?

Also, would you update the scion submodule pointer in [1] so that I
can pick this up for our web-browser-less SpiderMonkey integration?

(I'm optimistic that I won't need to define a custom send as it looks
like your implementation of #_internal translates the send to a
raise.)

Regards,
Matt

[1] git://github.com/jbeard4/pySCION.git

[Jacob Beard]

On Fri, Nov 2, 2012 at 2:43 AM, MattO <matt....@gmail.com> wrote:

Thanks for the quick turnaround, Jacob.

Would you remove the rogue console.log from  lib/core/util/code-gen.js:131?

Also, would you update the scion submodule pointer in [1] so that I
can pick this up for our web-browser-less SpiderMonkey integration?

Done. 

Note that I've updated SCION to make it easier to embed. I still need to write up documentation on this, which I'll do soon, but pyscion is still the best example of how to embed SCION in other environments.

 

(I'm optimistic that I won't need to define a custom send as it looks
like your implementation of #_internal translates the send to a
raise.)

I agree. Internally, built-in function $raise is used to send an internal event, and $send is used to send external events. The implementation of send/@target='#internal' delegates to $raise, so if you're only using send/@target='#internal', then you shouldn't need a custom send implementation.

Best,

Jake

[MattO]

Hi, Jacob,

I grabbed the latest pySCION. It's been a while.

In the version of scion I've been using, you had schooled me on
loading in a string that I'd previously converted to JSON using
jsonml.xslt from [1]. I could then

test_src = ["scxml",{"version":"1.0","profile":"ecmascript","initial":"init"},
...

annotator = require('core/util/annotate-scxml-json')
json2model = require('core/scxml/json2model')
engine = require('core/scxml/SCXML')
annotated = annotator.transform(test_src)
model = json2model(annotated)
opts = {log: function(s) { print(s); }}
interp = new engine.SimpleInterpreter(model, opts)
interp.start()
interp.gen('someinput')

Looks like annotator.transform now wants a DOM.

Can you re-school me on how to inject a jsonml-ized scxml document into scion?

Matt

[1] https://github.com/mckamey/jsonml

[Jacob Beard]

Updated documents here: https://github.com/jbeard4/SCION/wiki/Embedding-SCION

I need to provide better comments for the big code snippet in section "Platform API", but this should get you started.

Jake

[Jacob Beard]

I just revised it with a more complete specification of the platform API: https://github.com/jbeard4/SCION/wiki/Embedding-SCION

This should be all that you need in order to use SCION in your embedded spidermonkey environment.

If you have any questions, please don't hesitate to ask. Thanks,

Jake

[MattO]

Hi, Jacob,

Thanks for the write-up.

A few things I've run into:

1. After make-ing pySCION, I got a syntax error attempting to load the
generated scion.js into the SpiderMonkey js shell. I discovered that
the generated scion.js contained a bunch of test code. I was able to
address this by appending the following to js-src/build/stitch.js:

path.join('js-lib','scion','lib','external','sax-js','examples'),
path.join('js-lib','scion','lib','external','sax-js','test'),
path.join('js-lib','scion','lib','external','xmldom','test'),

2. scion.js and its uglified counterpart seem to have gotten pretty
big since I last integrated:

Old:
97,162 scion.js
33,111 scion.min.js

Latest:
230,861 scion.js
101,262 scion.min.js

Even with the adjustment from #1 above, am I stitching in more than necessary?

3. The DOM implementation provided with SCION looks to require
getter/setter support. Unfortunately, that doesn't appear to be
supported even via es5-sham/shim in SpiderMonkey 1.7. Here's what I
tried / am running into:

js> load('es5-shim/es5-sham.js')
js> load('es5-shim/es5-shim.js')
js> load('JSON/json2.js')
js> load('pySCION/scion.js')
// load in a string assigned to a variable (s) containing a simple
scxml document
js> load('scxmldoc.js')

js> scion.ext.platformModule.platform.parseDocumentFromString(s)
es5-shim/es5-sham.js:188: ReferenceError: owns is not defined

If I attempt to correct that by adding the following:

function owns(o, p) {
return typeof p !== 'undefined' ? o != null && o.hasOwnProperty(p) :
this.hasOwnProperty(o);
}

I run into:

/es5-shim/es5-sham.js:223: ReferenceError: supportsAccessors is not defined

js> supportsAccessors = false
js> scion.ext.platformModule.platform.parseDocumentFromString(s)
es5-shim/es5-sham.js:265: getters & setters can not be defined on this
javascript engine

js> supportsAccessors = true
js> scion.ext.platformModule.platform.parseDocumentFromString(s)
es5-shim/es5-sham.js:228: ReferenceError: defineGetter is not defined

Not sure how to workaround that since I'm stuck with 1.7. Any
possibility your DOM implementation could be implemented without
dependence on defineProperty get/set?

Matt

[Jacob Beard]

Hi Matt,

Sorry for the confusion. I believe the issue is as follows:

The intention behind SCION is that it be portable. This is achieved by creating a platform object which encapsulates all platform APIs, and then injecting the platform to SCION. There are implementations of the platform API for node.js, rhino, and the browser environments in the lib/ directory (in node/, rhino/ and browser/ respectively). The lib/platform.js module loads and injects the appropriate platform modules for these three "blessed" environments.

However, I've also tried to make SCION clever so that it tries to fill in as much of the platform API as possible using pure-JavaScript libraries to make it as easy as possible to embed in other environments. This portable platform implementation is provided in lib/embedded/. 

I chose the xmldom library as a portable, pure-JavaScript DOM implementation to fill in the DOM part of the platform API, but it sounds like this library is not as portable as I thought, due to its dependency on getter/setter syntax. It therefore sounds like this dependency, rather than simplifying SCION embedding, is actually complicating it. 

As the next major iteration of SCION should eliminate the DOM dependency entirely (in favor of a simple SAX-like API), I've decided to remove xmldom and the other 3rd-party libraries I included. This means you should be able to build SCION for your spidermonkey environment in the normal way, and should run fine in spidermonkey 1.7.

This should also solve the problem of the increased build size.

I'll update SCION and pySCION with this change tomorrow and let you know when to pull the update.

Best,

Jake

[Jacob Beard]

SCION and pySCION have been updated. You should be able to use this as a base for building a version of SCION which can be run in your spidermonkey 1.7 application.

If you have any questions, please don't hesitate to ask.

[MattO]

Thanks, Jacob.

Last issue (I hope): the host container into which I'm integrating SCION implements a read-only subset of W3C DOM Level 2.

I can work around this by authoring charts that explicitly use <initial>, but I wonder if it would be reasonable to modify SCION to avoid writing to the DOM and instead create the initial states directly in its native internal data structure format.

Regards,
Matt

[Jacob Beard]

Normalization of initial states needs to occur somewhere. Right now, SCION uses DOM internally to achieve this, but it could be done in advance before being passed to SCION. For example, this normalization could be done using the following XSLT (borrowed from scxml-js): https://gist.github.com/4060570

SCION's IR is going to change significantly going forward to eliminate DOM as a dependency entirely, which will solve this problem implicitly, but this is a large update which is still in development. If you're stuck, I can look into working on this one issue, but otherwise, I'd rather wait until the big update is complete.

[MattO]

Thanks for the gist pointer, Jacob. That'll do just fine.

Regards,
Matt