[Bug 355] New: Featuritus: programs and state machines loadable in TaskContext

For more information about this bug, visit
A new bug was added:
Summary: Featuritus: programs and state machines loadable in
TaskContext
Product: RTT
Version: orocos-trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Real-Time Toolkit (RTT)
AssignedTo: orocos-dev [..] ...
ReportedBy: wim [dot] meeussen [..] ...

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
machine for your TaskContext, you simply need to construct one (Orocos provides
nice classes to create a state machine) inside your component in C++.

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.

Wim

[Bug 355] Featuritus: programs and state machines loadable in Ta

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.

wmeeusse's picture

[Bug 355] Featuritus: programs and state machines loadable in Ta

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.

[Bug 355] Featuritus: programs and state machines loadable in Ta

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.

[Bug 355] Featuritus: programs and state machines loadable in Ta

For more infomation about this bug, visit

Klaas Gadeyne <klaas [dot] gadeyne [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |klaas [dot] gadeyne [..] ...

--- Comment #5 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2007-10-15 09:17:40 ---
(In reply to comment #4)
> This discussion has been dead for a while, and I'm not convinced that this
> needs fixing. On the contrary, it is probably better for users to match the
> status of a scripting state machine to the status of a TaskContext, which is
> something other reports (#423, #424) tackle.

Maybe this should be another bugreport, but I still think that at least the
component builders manual should be more explicit about what is possible with
the scripting state machines and what is not. To me also (just as Wim reports
in the original bug report), after reading the component builders manual, it
appeared that scripting state machines were the way to go when using orocos
taskContexts.

regards,

Klaas

[Bug 355] Featuritus: programs and state machines loadable in Ta

For more infomation about this bug, visit

Peter Soetens

<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
CC| |peter [dot] soetens [..] ...

--- Comment #4 from Peter Soetens

<peter [dot] soetens [..] ...> 2007-10-14 22:51:02 ---
This discussion has been dead for a while, and I'm not convinced that this
needs fixing. On the contrary, it is probably better for users to match the
status of a scripting state machine to the status of a TaskContext, which is
something other reports (#423, #424) tackle.