For more information about this bug, visit
A comment was added:
------- Comment #3 from peter [dot] soetens [..] ... 2007-03-11 22:17

(In reply to comment #2)
> > Finally, if you, a user, feel that a StateMachine is not 'part of' a
> > TaskContext, it is a flaw in the documentation or in the RTT design itself.
> > Components have discrete states, components require state machines to manage
> > these, the RTT allows you to specify them in custom C++ code or as scripts.
> > Your choice.
>
> A statemachine _should_ always be a part of a TaskContext. In the current RTT
> design a C++ state machine _is_ a part of a TaskContext, but a scripting
> statemachine _is not_ a part of a TaskContext.
>

By which you mean it can not access the 'internal' C++ variables of a
TaskContext ? Why don't you turn the picture inside-out ? Store all the
'internal' variables as scripting variables in a state machine and access these
from your C++ code ? It's just a point of view.

Another note about the difference internal/public interface of a TaskContext: I
find it a 'good' practice to put all public variables, methods etc of a TC in
the 'this' object, while all internal members are stored in task objects. Thus
you could make a TaskObject 'private' and access that one from both C++ and
scripted state machines.

For more information about this bug, visit
A comment was added:
------- Comment #2 from wim [dot] meeussen [..] ... 2007-03-08 11:18

> Finally, if you, a user, feel that a StateMachine is not 'part of' a
> TaskContext, it is a flaw in the documentation or in the RTT design itself.
> Components have discrete states, components require state machines to manage
> these, the RTT allows you to specify them in custom C++ code or as scripts.
> Your choice.

A statemachine _should_ always be a part of a TaskContext. In the current RTT
design a C++ state machine _is_ a part of a TaskContext, but a scripting
statemachine _is not_ a part of a TaskContext.

For more information about this bug, visit
A comment was added:
------- Comment #1 from peter [dot] soetens [..] ... 2007-03-08 10:01

(In reply to comment #0)
> In the current implementation of a TaskContext it is possible to load a state
> machine or a program script into the TaskContext. I think this was implemented
> with the idea that a TaskContext has an internal state machine, and it would be
> nice to be able to write this internal state machine in scripting. Wowever
> (yes, however, otherwise this wouldn't be a bug report), this scripting state
> machine cannot be the _internal_ state machine of a TaskContext because the
> scripting state machine can only access the _external_ interface (methods,
> commands, events, etc) of the TaskContext. If you want an internal state

Well, there is no such thing as an internal interface from the scripting point
of view. This follows the Python philosophy a bit, where objects have no
private members either. Developers are marking data members as internal by
naming convention (for example, by prefixing them with 'm' or '_').

> machine for your TaskContext, you simply need to construct one (Orocos provides
> nice classes to create a state machine) inside your component in C++.

The C++ 'StateMachine' class is not a nice class. It sits there solely for the
scripting and its interface is not user friendly at all. There is need for a
StateMachine subclass which translates the current interface to a more usable
form.

>
> So the message is that the possibility to load a state machine or a program
> script into the TaskContext is useless, and IMHO should be removed.

Which is off course unacceptable. Application code (user algorithms) are always
executed by a TaskContext's ExecutionEngine. Be it a command or a state
machine. Now I understand that in most applications today, most components do
not have a program or statemachine script loaded (just like most components do
not process events), and only the 'supervisor' component uses these scripts to
control other components. Now if we generated our components, we could
selectively remove unneeded functionality, but we're not doing this yet, hence,
we can't start cutting people's hands off without offering them an alternative.
I'm particularly thinking about single component applications as well, in which
one component 'does it all'.

Finally, if you, a user, feel that a StateMachine is not 'part of' a
TaskContext, it is a flaw in the documentation or in the RTT design itself.
Components have discrete states, components require state machines to manage
these, the RTT allows you to specify them in custom C++ code or as scripts.
Your choice.