scxml: nested custom actions

2016-03-19 Thread R.C. Hoekstra
Hi Ate, Woonsan, 

Is there a way to access nested child actions from a parent custom action in 
scxml? 

In version scxml-2.0-M1 I could do this in the onexecute of a custom action: 

for (Action action : getParent().getActions()) {
   if (action instanceof MyChildAction) {
  // do things with child action


In M1 the Executable.getActions() would list all actions, also the nested child 
actions contained in a parent action.  In the most recent code the 
Executable.getActions() only lists the parent action, NOT it's children. 


I want to do something like this: 


 


 


So how to access the childActions from the parentAction's onExecute? 


thanks in advance, 

Rinke


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: Re: [scxml] update and progress?

2015-12-04 Thread R.C. Hoekstra
Hi Ate, 

thanks for answering. 

As for the datamodel...
Well, I put the stuff in our project which depended on the datamodel on hold. 
We wanted to apply a datamodel in order to separate the state flow logic and 
the numbers used in it, but we haven't done that up to now, because I was 
afraid that the datamodel on scxml commons would become subject of serious 
changes. 

So for us it's still very flexible, as we didn't start with that part yet. I 
have a slight personal preference for at least the xml in the datamodel, but 
it's not that important. For us the progress of the project is much more 
important than the choice on which language support will be there and which 
not. 
So I can perfectly live with JSON. And if your proposal leads to greater ease 
of use and faster implementation, that is fantastic. Please do so. 

The support for java8 is also fine with me. We're doing everything in java 8.

So conclusion: your proposal is supported from over here!

best regards, Rinke




Hi Rinke,

On 2015-11-24 12:24, R.C. Hoekstra wrote:
> Hi Ate, Woonsan,
>
> I was wondering if you guys could give us an update on the progress of
> SCXML, and tell us how it's going.
>
> Specifically, I was wondering if you could give us any clue on when
> Milestone 2 can be expected. I'm looking forward to the new datamodel
> features with great interest.
>
> I don't see much questions and activity on the mailinglist on scxml, but I'd
> like you to know that we are still very enthousiastic on the scxml project.

That is great to hear, and thank you for saying so!

Obviously there hasn't been much progress since early this year :(

Main reason for this is that the current M1 release has been sufficient for our
current use-cases, so far, and we thus right now don't have a real business
driver nor concrete budget/time to work on this during working hours, 
regrettably.

That doesn't mean I (and Woonsan) are no longer interested in working on this,
but can only do so on our own account outside office hours.
And as we've been very busy with lots of other work, you probably can understand
that working on Commons SCXML kind of ended up on the back burner.

Also there hasn't been much input from the 'community' either...

That said, your question tricked me in reviewing again the current state and
outstanding issues, for M2 and beyond, and what can/should be done next.

And I now realize again that another reason why I 'dropped the ball' since last
February is that at that time I reached several technical and frustrating
problems in the current functionality, concerning both the Javascript and XPath
datamodel support.

As you might know, the now final SCXML 1.0 specification at the end dropped the
XPath support because there were no concrete implementations, because of lack of
interest and too many complications and limitations with XPath to be able to
provide a proper implementation.

And those same complications and limitations are also causing serious and
invasive problems in the (overall) implementation in Commons SCXML.
Honestly, I'm fed up with the XML/XPath datamodel as it is hampering and
complicating the implementation way too much.

Therefore, I want to propose to completely drop XML/XPath datamodel and language
support for Commons SCXML 2.0, before moving on with completing and wrapping up
the goals for M2.

This however is a very radical change, including dropping the support for the
Data() and just added Location() functions for the Jexl and Groovy languages.
Instead however, I would like to replace this by providing proper JSON datamodel
support, not just for Javascript but also the Jexl and Groovy languages.
Technically and functionally this will be:
- much easier and straightforward to implement with a lot less edge-cases
- much easier and practical to use

And in addition, for proper Javascript support we should move to Java 8
(Nashorn Javascript engine), and thus drop support for Java 6 and 7.

But before doing so, this needs to be discussed and agreed upon by the
Commons SCXML community, however small a group that might be nowadays.

I hope you and others can comment on this idea and provide feedback if you
would be OK, or why not.
If for example you or others strongly depend and rely on XML datamodel support,
than this might be a no go, unless you are fine with migrating from XML/XPath to
JSON instead.

If we can make this decision: drop XML/XPath support, add JSON as alterative,
and move to Java 8 as minimum, then we can move forward much faster and with a
much cleaner and leaner implementation.
I'd then be happy and motivated again to continue working towards M2 shortly,
and I know Woonsan is willing to pitch in then as well.
That might still need a few months work to complete, but definitely overseeable.

Kind regards,
Ate


[scxml] update and progress?

2015-11-24 Thread R.C. Hoekstra
Hi Ate, Woonsan, 

I was wondering if you guys could give us an update on the progress of SCXML, 
and tell us how it's going. 

Specifically, I was wondering if you could give us any clue on when Milestone 2 
can be expected. I'm looking forward to the new datamodel features with great 
interest. 

I don't see much questions and activity on the mailinglist on scxml, but I'd 
like you to know that we are still very enthousiastic on the scxml project. 

best regards, 

Rinke
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: Re: Re: [scxml] bug with script in combination of a chain of transitions

2015-07-07 Thread R.C. Hoekstra
Hi Ate, 

Ah, I understand the issue now. Thanks for looking at it. 

best regards, Rinke
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: Re: [scxml] bug with script in combination of a chain of transitions

2015-06-28 Thread R.C. Hoekstra
Hi Ate, 

Sorry I forgot to mention, it's 2.0-SNAPSHOT. 

Thanks for looking at it. 

best regards, Rinke


> Date  Mon, 22 Jun 2015 23:10:21 GMT
> Hi Rinke,
> 
> I will try to take a look at your issue later (end of) this week.
> It would be helpful if you can report against which version you are 
> experiencing 
> this behavior: current 2.0-SNAPSHOT or earlier milestone 2.0-M1 or 2.0-M0?
> 
> Thanks, Ate
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: Re: [scxml] bug with script in combination of a chain of transitions

2015-06-15 Thread R.C. Hoekstra
pache.commons.scxml2.model.Log execute
INFO: null: logging in test1.3
May 05, 2015 11:45:47 PM org.apache.commons.scxml2.env.SimpleSCXMLListener 
onEntry
INFO: enter /test1/test1.3

(I typed 'test1.1.positive' and 'test1.2.positive' to trigger those events 
manually.)

So, the execution order is as follows:
1. enter into test1 state
2. execute actions in onentry of test1.1 state
3. enter into test1.1 state and wait
4. 'test1.1.positive' event triggered manually
5. exit from test1.1 state
6. transition from test1.1 to test 1.2 state
7. execute actions in onentry of test1.2 state
8. enter into test1.2 state
9. 'test1.2.positive' event triggered manually
10. exit from test1.2 state
11. transition from test1.2 to test1.3 state
12. execute actions in onentry of test1.3 state
13. enter into test1.3 state

I don't think  action would be different from <log> action in execution
ordering, so I think you're seeing a different result on your end for some 
reason. Maybe you
can try to find what the difference comes from?

Regards,

Woonsan

[1] <a  rel="nofollow" href="http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html">http://commons.apache.org/proper/commons-scxml/guide/testing-standalone.html</a>



On Fri, 4/17/15, R.C. Hoekstra <r.c.hoeks...@erasmusmc.nl> wrote:

 Subject: [scxml] bug with script in combination of a chain of transitions
 To: "user@commons.apache.org" <user@commons.apache.org>
 Date: Friday, April 17, 2015, 4:12 AM
 
 Dear people at scxml, 
 
 I found a bug in the scxml commons project. 
 
 Consider this scxml file: 
 
 <state id="test1" initial="test1.1">
 <state id="test1.1">
 <onentry>

 <ntd:test id="test1.1" isIn="test1.1" />

 <script> agent.storeInMemory("test1.1");
 
 
 
 
 
 

 
 
 
 
 
 
 
 There is a custom tag, which simply tests if the state
 machine is at present in the state specified in the "isIn"
 attribute. If it is, it sends an event .positive,
 else it sends .negative.
 The purpose of this is that we needed a memory: a test that
 the state machine has at any moment been in a certain state.
 That is done via the script tag: via the
 agent.storeInMemory("test1.1") call, the test1.1 state is
 stored in the memory of the agent, and ntd:test tag
 considers this memory if the memory=true attribute is
 specified. As the state test1.1 is stored in memory while
 being in state test1.1, the test of test1.2 should return
 positive, and the test1.2.positive event should be send.
 
 However, this tests fails. 
 The problem is that the script tag appears to be only
 executed AFTER the chain of all transitions has been
 executed and finished, and so the call of the script is too
 late for the test.  I had expected the script tag to be
 executed at entering state test1.1, and not only after
 having passed test1.1 and being already in test1.2
 
 
 The order of entries is also weird: the log shows this
 order: 
 
 onentry: test1
 onentry: test1.2
 onentry: test1.1
 
 So you should expect that the onentry for 1.2 happens after
 1.1, but it is reversed. 
 
 best regards, Rinke
 
 
 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org
 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



[scxml] bug with script in combination of a chain of transitions

2015-04-17 Thread R.C. Hoekstra
Dear people at scxml, 

I found a bug in the scxml commons project. 

Consider this scxml file: 





 agent.storeInMemory("test1.1"); 












There is a custom tag, which simply tests if the state machine is at present in 
the state specified in the "isIn" attribute. If it is, it sends an event 
.positive, else it sends .negative.
The purpose of this is that we needed a memory: a test that the state machine 
has at any moment been in a certain state. That is done via the script tag: via 
the agent.storeInMemory("test1.1") call, the test1.1 state is stored in the 
memory of the agent, and ntd:test tag considers this memory if the memory=true 
attribute is specified. As the state test1.1 is stored in memory while being in 
state test1.1, the test of test1.2 should return positive, and the 
test1.2.positive event should be send.

However, this tests fails. 
The problem is that the script tag appears to be only executed AFTER the chain 
of all transitions has been executed and finished, and so the call of the 
script is too late for the test.  I had expected the script tag to be executed 
at entering state test1.1, and not only after having passed test1.1 and being 
already in test1.2


The order of entries is also weird: the log shows this order: 

onentry: test1
onentry: test1.2
onentry: test1.1

So you should expect that the onentry for 1.2 happens after 1.1, but it is 
reversed. 

best regards, Rinke


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



[scxml] xsd schema

2014-12-27 Thread R.C. Hoekstra
Hi list, 

We have fairly complex scxml files and would like to validate them against a 
schema. I know there are the schema files from w3c, but the scxml files do not 
validate by those. 

The problem is we are using the state src attribute, which is not in that 
schema (but which can easily be added). However, validation still fails because 
with multiple files you can refer to state id's which exist in the other files 
referenced via src. 

I was wondering if anyone has an adapted scxml schema for this. 

best regards, Rinke
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: Re: [scxml] passing datamodel elements into method call

2014-10-17 Thread R.C. Hoekstra
Thanks Woonsan, Ate, 

I think I can work that out. 

best regards, Rinke
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



Re: Re: [scxml] passing datamodel elements into method call

2014-10-08 Thread R.C. Hoekstra
> Hi Rinke,
> I think you would get a node if you used DataNode function instead:
>  expr="DataNode(treatmentData,'treatments/treatment[1]/name')" />
> Could you try that?
>
> Regards, Woonsan
>

Hi Woonsan,

thanks for your answer. But are you sure about that?
If I use it like that, I get an "unknown, ambiguous or inaccessible method 
dataNode" error.

I found the dataNode method in Builtin.java. Its javadoc says:

"Manifests within location attribute of  element, for Commons JEXL and 
Commons EL based documents."

So what I get from it, is that dataNode can only be used to assign something to 
a dataNode via .

That is not what I want. I want to pass a dataNode including subElements to 
some java object via the cond attribute, so I can write a java method which is 
able to check conditions with use of the passed dataNode.


So: is there a way in which I can pass a dataNode to a java object in the 
context which is used in a cond attribute? Data obviously doesn't work, as I 
can see in the Builtin code that it always is parsed to Double or String.

best regards, Rinke





> On Thursday, October 2, 2014 3:53 AM, R.C. Hoekstra 
>  wrote:

> > Hi list, Hi people @ scxml commons,
> >
> > Can I pass datamodel nodes to a rootContext var, in order to process it in 
> > java?
> >
> > like this:
> > ,
> > where:
> > * agent is an object of a java class made available to the RootContext, 
> > having a check method returning Boolean. I want this check method to 
> > evaluate the
> > datamodelNode, in order to return true or false depending on elements.
> > * datamodelNodeRef is a reference to some node in the datamodel.
> >
> > I managed to pass final nodes as string here, like this:
> >
> >  > expr="Data(treatmentData,'treatments/treatment[1]/name')" />,
> >  >
> > where the treatments/treatment[1]/name is a final node.
> >
> >
> > However, I would like to pass non final nodes of the datamodel, but 
> > everything seems to be evaluated as strings first, before it is passed into 
> > the method of the context
> > var.
> >
> > Hope you can give me a clue.
> >
> > And, if these kind of constructions are possible, how would they do in 
> > terms of performance?
> >
> > thanks, Rinke



[scxml] passing datamodel elements into method call

2014-10-02 Thread R.C. Hoekstra
Hi list, Hi people @ scxml commons,

Can I pass datamodel nodes to a rootContext var, in order to process it in java?

like this:
,
where:
* agent is an object of a java class made available to the RootContext, having 
a check method returning Boolean. I want this check method to evaluate the 
datamodelNode, in order to return true or false depending on elements.
* datamodelNodeRef is a reference to some node in the datamodel.

I managed to pass final nodes as string here, like this:

,


SCXML: context thinks it is in no state at all in onentry of non atomic states.

2014-09-02 Thread R.C. Hoekstra
Hi all at scxml.



In my project I found some behavior which I regarded as unexpected, but maybe 
I'm overlooking something. In non-atomic states action execution the engine 
reports to be in no state at all.



I made a test Action class which only does one thing: it prints the result of 
SCXMLExecutor.getStatus().getAllStates() in a listing to StdOut.



Consider the following simple scxml file:





   







   





This shows the following output:

entering entry

exiting entry

   my prints 1 state: "1"

entering 1



Placing the onentry in an atomic substate like this:





   



   





shows the following output:

entering entry

exiting entry

entering 1

my prints 2 states: 1 and 1.1

entering 1.1





However, placing the onentry in the parent of that atomic substate like this:













gives a result which I hadn't expected:



entering entry

exiting entry

   my prints 0 states

entering 1

entering 1.1



Here, the action reports that the engine is in NO STATE AT ALL.

I can see that the action is always executed before the listener reports it's 
onentry (of which I'm not sure if it's weird or not), but nevertheless it 
always reports correctly the states it belongs to. Except when the action is 
executed on a non-atomic state -> then it believes to be in 0 states.



This looks to me like inconsistent, and thus a bug, or am I overlooking some 
logic?



Test classes are available at request.



best regards, Rinke


[scxml] profiling scxml commons

2014-06-18 Thread R.C. Hoekstra
Hi all @ scxml commons. 

We had some profiling done on our scxml multi agent simulation project. Our 
issue is that scxml is too slow. We need about 100,000 instances of scxml 
engines for a multi agent simulation, and tests show that the approach with 
scxml is over 10 times slower than an alternative but less flexible approach. 
Still, the flexibility of the scxml commons project serves us very well, so we 
need to look for ways to improve the performance. 

For our project setup see my mailing to this list on Fri, 30 May, 20:45.

We have the following tips and improvements: 

1) Now, there's a logger applied for each instance, which is inefficient. 

Make default Log in SimpleContext static. In 
SCXMLExecutionContext/SCXMLExecutor, it can be static final even.
public class SimpleContext implements Context, Serializable {
   /** Implementation independent log category. */
   private static final Log DEFAULT_LOG = LogFactory.getLog(Context.class);
   private  Log log = DEFAULT_LOG;


2)  SimpleContext containsKey() + get() to get()

you can rewrite SimpleContext to:
   public Object get(final String name) {
Object localValue = getVars().get(name);
   if (localValue!=null) {
return localValue;
   } else if (parent != null) {
   return parent.get(name);
   } else {
   return null;
   }
   }


We think item 1) & 2) will lead to a 30-50% improvement in our scenario, and 
they are very simple to apply. 


3) Other issues we are not sure about: 

- Status.getAllStates can probably be cached: Difficult to determine if this 
can be done since the states member is writable from outside and not sure when 
this getAllStates() cache should be invalidated. But it takes up quite some 
time.

- SCXMLSemanticsImpl.isLegalConfig is probably a paranoia check, can we disable 
it?


4) Some questions about further speed improvements: 

4a) scripting:

In the configuration as given, about 10% is spend in JEXL scripting. Depending 
on how much we want to do with that, we could switch to another scripting 
implementation (would require some benchmarking) or maybe move some of the 
scripts into the Java domain.

Do you guys have any clues about which of the provided scripting 
implementations is expected to be the fastest? Are there other possibilities to 
improve the scripting performance?


4b) initializing / common stuff:

What happens now is that each StateMachine engine (SCXMLExecutor) is 
instantiated a thousand times, once for each agent. Maybe it's possible to move 
some of the stuff to some common initialization where it is now done for each 
agent. Do you see any opportunities here?


Thanks, 
kind regards, 

Rinke Hoekstra.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



[scxml] Re: Re: Re: our project setup: any tips specifically on performance/speed?

2014-05-30 Thread R.C. Hoekstra
Hi Ate, hi list, 

I can share some more information now, and post some code. 

First of all, on our project: 

No, we don't use threads at the moment. Multithreading seems to become a 
nightmare with over 100 k engine instances. 

We also don't use the  tags at the moment. As datamodel is still in 
the planning according to the roadmap, I found it a bit dangerous to rely on 
it. Also, it does seem a bit inconvenient for our purpose, but if that's not 
the case I'm happy to become convinced of the contrary.

(De)Serialization is not an issue at the moment, though it might become an 
issue in the future. We're considering two strategies: Maybe just log every 
transition and do analysis on that log with some tool. Or dump the whole 
population of 100,000 agents / scxmlExecutor instances every now and then at 
fixed times in some database structure for further analysis. We are still open 
to suggestions, what this concerns, though that is of course not really an 
scxml issue. 
For the rest: the simulation is just running in memory, and for now that 
doesn't seem to be a problem for the hardware. 

So here are some key parts of our code / setup (Ate, I can post them without 
problems now). 
Main question is: which are the elements which are possibly a bottleneck for 
the performance, and are there any alternatives for these elements? 


So the disease is modelled by an human.scxml file which defines the states of 
the disease. Example:




agent.infectivity = 0.2




 


The ntd:schedule tag is responsible for scheduling the transitions in our 
EventManager. The Action class responsible for this uses the attributes to draw 
a random number and schedules the passed event with the resulting time in our 
own eventManager. When that scheduled time has come, the eventManager sends the 
event back to the state machine instance in order to invoke the transition.
The chances attribute defines the chances for each transition defined: it is a 
space separated list of doubles indicating transition chances. In this case the 
first transition should get a chance of 0.01 of happening, and as there is no 
other number given, the final remaining transition gets a chance of 0.99 to 
happen. The index number of the transition is passed back via the payload and 
tested in the cond attribute of the transition. 

The script tag is responsible for setting agent properties - in this case the 
infectivity. Each agent has an own SCXMLExecutor instance, and sets itself to 
the executor's rootcontext, so it can be accessed in the scxml files. Each 
agent is also its own scxml Listener.
All is single threaded. I think the EventManager is smart enough to handle and 
store 100,000 or more scheduled events. The EventManager is passed to our own 
implementation of Evaluator, which is simply a child class of JexlEvaluator, 
but with awareness of math (statistic distributions & random number generator), 
eventManager and the time running in the simulation. 

Then, we also need to model treatments. So we have one main scxml file with the 
following content.



 










So biology definitions define the disease itself, and all its states; 
treatments define how patients are treated: subjects will pass states 
"untreated", "tested" and various possible treatments. As treatments can happen 
in various states of the disease, I though it best to use parallel states here. 
A treatment raises events which in "biology" will cause the patient to recover. 

I hope this is enough to give a rough picture, and I hope you guys could point 
out some performance bottlenecks. I understand however that most performance 
bottlenecks are expected to be in the IO/(de)serialization part. 
I could post some more code snippets if that is helpful or interesting.


thanks, best regards, Rinke

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



[scxml] Re: our project setup: any tips specifically on performance/speed?

2014-05-30 Thread R.C. Hoekstra
Hi Woonsan, Hi Ate, 

(sorry for the late response)

Woonsan wrote:

> If the estimate of the pure SCXML executions can possibly meet your 
> requirements, then I think
> the next thing to consider might be how to reduce IOs if you have to 
> (de)serialize those instances.
> In one of our projects, we initialize a root context and an executor every 
> time before triggering
> events. So, the SCXML definition is responsible for initializing itself (to 
> move the right
> current state) from the given root context (in script blocks). I think this 
> pattern could
> help reduce the amount of (de)serialized data, and so reduce IO.

We haven't given the (de)serialization lots of attention yet. Of course, 
potentially it can be quite heavy with a few 100.000 of instances, but I don't 
know yet what is exactly needed. 
Your pattern sounds interesting, but can you please point out some link to that 
project, so I can get the real picture clear? 

thanks for the response, 

Rinke

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



our project setup: any tips specifically on performance/speed?

2014-05-11 Thread R.C. Hoekstra
Hi list, 

As written before, We're a university team of scientists working on multi agent 
simulations of tropical diseases for a world health organization project. A 
disease can be considered as a state machine, with the patient going through 
various states and transitions, each triggering new events.

We've managed to make a working example of a xml file where a patient is going 
through various stages of the disease, including treatments with medicine. Our 
most important concern at the moment is: how efficient is it? Our aim is a 
multi agent simulation with possibly a few 100,000 of instances of a State 
Machine engine (SCXMLExecutor). I'd like to share the code setup with you guys, 
and maybe you can give some clues on how efficient it will be in terms of 
performance/speed, and maybe some hints if an alternative approach would be 
better?

general setup
we have a Population object (a wrapped list) containing all agent objects. Each 
agent is assigned an SCXMLExecutor as the engine, so there are many instances 
of SCXMLExecutor. We use the default JexlEvaluator, and each SCXMLExecutor gets 
the agent it belongs to assigned to the rootContext, so the agent's properties 
can be accessed from the scxml file. 

Transitions
Our transitions are usually of a special type: a patient usually stays x days 
in a certain state, after which the transition takes place. The x days is 
determined on basis of drawing a random number from a statistical distribution. 
There is usually more than one possible transition; each with different 
probabilities. 
So the scxml file must contain the following information: 
* distribution name and parameters to determine the time until next transition.
* A number coupled to each possible transition indicating the likelyhood that 
it happens. 

We solved this in the following way:
* distribution name, mean and variance parameters, and chances are defined in 
the datamodel as single variables: 
in each state's onentry we set these variables with the values specific for 
that state, via the assign tag. The chances variable is defined as an array: 

* The state's onentry also contains a send tag. Send passes the agent's id, the 
forementioned variables and the event concerned. 
The send message is captured by our own implementation of EventDispatcher. This 
does two things: 
** It draws the random time based on the passed distribution parameters. It 
schedules this in our own discreet event manager. When the desired time has 
passed, the discreet event manager passes the correct event back to the correct 
SCXMLExecutor instance. 
** It determines which transition will be chosen by drawing a random number on 
basis of the chances array. This results in an index number of the transition 
to be chosen. This index number is passed as payload to the event. The scxml 
file checks this index number in the cond attribute of the transitions.

Agent properties:
Each disease state also has its effect on the agent's properties, for example 
the infectivity of the agent, or its fitness. The agent was passed to the 
rootContext, so the onentry of each state contains code to set the agent's 
properties specific to that state: 

agent.infectivity = 1


This is our overall approach. I'd be happy to receive any comments; 
specifically tips regarding the expected speed/performance. 

best regards,
Rinke

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



RE: Re: scxml: planning and versions

2014-04-19 Thread R.C. Hoekstra
Hi Ate, Woonsan, 

thanks for the long answer; sorry for my late reply, I was away for a few days. 

Good to hear you are really interested in our use-case, Ate. 

You're asking what specific specification features we will be using now, or in 
the near future. To be honest; I don't know yet. At the moment we are still in 
the stage of settings things up, and we are exploring all the possibilities 
scxml offers to our project. 

Because to launch out here about our project features wouldn't fit anymore in 
the subject of this thread, I will soon post a subject about our project, and 
then maybe you guys can advise us some more on the best features to use. 

best regards, Rinke
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



scxml: planning and versions

2014-04-15 Thread R.C. Hoekstra
Hi all @ commons scxml,

We're a university team of scientists working on multi agent simulations of 
tropical diseases for a world health organization project. A disease can be 
considered as a state machine, with the patient going through various states 
and transitions, each triggering new events.

For our project we're diving into commons scxml. However I'm a bit confused 
about what version would be best to use. I'm a bit afraid that the 0.9 official 
release is so much outdated that it will not be compatible with the coming 
release, so we would end up with lots of changes to be made when updating. On 
the other hand working on a release which is still under development or 
unstable doesn't seem a good idea.

Is the J6 branch on the svn.apache.org repository a good idea (1.0)?

Can you give some clues in when the first 2.0 release can be expected?

Thanks, Rinke

by the way: thanks for all the good work done. I think it is a great project. 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org