Master introduce v1cmd syntax

[psoetens]

This adds the RTT v1 command semantics to operations used in RTT scripts, by introducing a .cmd() method, analog to .send() and .call(). An operation invoked with .cmd() will wait in a non-blocking way for the operation to complete. So this can mainly be used in periodically executed components, which call operations which take a long time to execute in non-periodic components.

To be discussed, but not to be merged into toolchain-2.8

[meyerj]

merged into toolchain-2.9: 2af3745

[meyerj]

Commit faf49ed breaks the state_test:

19.181 [ Info   ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER, priority=1, CPU affinity=0, with name='root'
19.181 [ Info   ][root] Thread created with scheduler type 'ORO_SCHED_OTHER', priority 0, cpu affinity 255 and period 0 (PID= 11112 ).
19.181 [ Info   ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER, priority=1, CPU affinity=0, with name='caller'
19.181 [ Info   ][caller] Thread created with scheduler type 'ORO_SCHED_OTHER', priority 0, cpu affinity 255 and period 0 (PID= 11113 ).
19.182 [ Info   ][ProgramLoader::loadProgram] Parsing file func.ops
19.188 [ Info   ][ProgramLoader::loadProgram] Exported Function 'foo' added to task 'root'
19.188 [ Info   ][ProgramLoader::loadProgram] func.ops : Successfully parsed.
19.188 [ Info   ][ScriptingService::loadStateMachine] Parsing file state_test.cpp
state_test: /opt/orocos/indigo/src/orocos_toolchain/rtt/rtt/scripting/SendHandleAlias.cpp:75: virtual RTT::scripting::SendHandleAlias* RTT::scripting::SendHandleAlias::copy(std::map<const RTT::base::DataSo
urceBase*, RTT::base::DataSourceBase*>&, bool): Assertion `(inst == false) && "SendHandleAlias may not be instantiated !"' failed.
unknown location(0): fatal error in "testStateSendFunction": signal: SIGABRT (application abort requested)
/opt/orocos/indigo/src/orocos_toolchain/rtt/tests/state_test.cpp(1949): last checkpoint

[meyerj]

Commit faf49ed breaks the state_test:

Fixed in psoetens@d444550.

[meyerj]

The state_test is still broken:

/opt/orocos/indigo/src/orocos_toolchain/rtt/tests/state_test.cpp(949): error in "testStateSendFunction": check sa->getStateMachine( "x" )->inState("FINI") failed

The failing test case testStateSendFunction runs the following state machine:

export function foo(int arg) {
  do test.assert( tvar_i == arg ) 
  do test.assert( tvar_i != tconst_i ) 
  set tvar_i = tvar_i+2
  do test.assert( tvar_i == arg + 2 ) 
}

StateMachine X {
 initial state INIT {
  run {
   tvar_i = 0

   var SendHandle sh, sh2
   sh = foo.send(tvar_i) 

   sh // tests accidental sh evaluation

   test.assert( sh.collectIfDone() == SendNotReady )
   test.assertEqual( tvar_i, 0 )

   while ( sh.collectIfDone() == SendNotReady) 
      yield
   test.assert( sh.collectIfDone() == SendSuccess )
   test.assertEqual( tvar_i, 2 )

   sh2 = foo.send(tvar_i) 
   test.assert( sh2.collectIfDone() == SendNotReady )
   test.assertEqual( tvar_i, 2 )
   while ( sh2.collectIfDone() == SendNotReady) 
      yield
   test.assert( sh2.collectIfDone() == SendSuccess )
   test.assertEqual( tvar_i , 4 )
  }
  transitions {
     select FINI
  }
 }
 final state FINI { // Failure state.
  entry { do test.assert(true); }
 }
}

The problem is that the condition of the first while loop in the run program never evaluates to false and that every evaluation of sh.collectIfDone() resends the foo operation, which is executed in every yield cycle. The run program never finishes and therefore the final state test fails.

[meyerj]

The state_test is still broken:

The last two commits (f82fa9a and 361fe29) seem to fix the issue.

[meyerj]

I am not sure if this is the expected behavior for the send() call type of a function:

Deployer [S]> scripting.eval("void test() {}")
 = true                
Deployer [S]> var SendHandle sh = test.send()
Semantic error: Attempt to initialize a var SendHandle with a SendStatus.
Deployer [S]> sh
 = (SendHandle)        
Deployer [S]> var SendHandle sh2
 = (SendHandle)        

Deployer [S]> sh2 = test.send()
 = SendNotReady        

Deployer [S]> 

Why can the result of test.send() not be assigned to a new SendHandle variable sh? Why does the second assignment to sh2 does not give the same error?

Should FunctionFactory::produceSend() not always return a SendHandle data source here? But FunctionFactory::produceHelper() returns a CmdFunction which is a SendStatus data source in FunctionFactory.cpp:230. I think the correct solution would be to add a new method produceCommand() to the OperationInterfacePart base class and implement it for functions. produceSend() could be left unimplemented as before or requires another solution.

Did the last commit 361fe29 introduce this bug?

[meyerj]

I am tempted to at least partially revert this patch in the toolchain-2.10 branch for the upcoming release. It still has unresolved issues (#84 (comment)) and introduces new complexity.

The .cmd() syntax only restores a small part of RTT v1 Commands and applies it to RTT v2 operations, namely that they can be called from Orocos scripting in a way that is equivalent to send + yield in a loop:

// instead of:
operation.cmd(1.0, "string argument");

// ... you can write:
var SendHandle sh = operation.send(1.0, "string argument");
while(sh.collectIfDone() == SendNotReady) {
  yield;
}

(which additionally allows to return the results as reference arguments to collectIfDone()). I am not sure from the documentation whether invoking a command from scripting was actually blocking in v1 or not. At least it was not when invoking a command from the OCL TaskBrowser.

The implementation side of RTT v1 commands was not restored in this PR. RTT v1 commands are stateful task primitives that allow the user to pass a non-blocking start callback and a completion condition to the RTT::Command constructor. The actual command execution was then completely up to the user and could be done in either the command function itself (blocking), other primitives based on the internal state, e.g. in the updateHook() or inside an Orocos state machine. In RTT v2 operations implemented as C++ functions always execute at once and there is no way to start an operation, yield and continue later. Once the C++ function returns, the operation is done and the results are returned to the caller.

Did I miss something? Any more thoughts? @psoetens? Is someone already using this new feature?

[snrkiwi]

I don't believe that the original intent was to fully implement the v1 Command syntax and implementation, but to give a useful approximation of it. But given the complexity I don't doubt that there are outstanding issues ...

Yes, we use this extensively to, for example, have state machines "block" on a long call while still checking (and potentially executing) transitions.