Yarpmanager to ensure stop wait

[pattacini]

Hi @apaikan,

It would be really great if yarpmanager could handle also wait states upon shutting down the modules of an application. Something like this:

<ensure>
   <wait>start="5" stop="3"</wait>
</ensure>

Being the following snippet interpreted as a start wait by default to keep back-compatibility:

<ensure>
   <wait>5</wait>
</ensure>

This behavior would come in handy to address those RTF tests whose fixture contains e.g. the simulator and lots of components altogether, that is where closing them all at once would produce weird results.

I believe we can get away simply with stop wait to deal with such an unusual case, instead of coming up with very-principled-yet-difficult-maybe-not-working approach 😜

[pattacini]

@Tobias-Fischer

Also, if/when this feature will be provided, it might have a terrific impact on how gracefully we'll be able to shut WYSIWYD main demo app 😃

[Tobias-Fischer]

That would be great indeed. It feels like this would be a great add-on for any project with a large amount of modules running. It would be great if @apaikan gets around in doing this - please let me know if I can help :).

Best,
Tobi

[pattacini]

@apaikan I didn't realize there was robotology/robot-testing-framework#54 to deal with multiple fixtures 👍

Do you think it'd be possible to implement the stop wait though? It can be still beneficial for the reasons detailed above.

[apaikan]

What about this?

<ensure>
   <wait> 5 </wait> <!-- by default  when='start' -->
   <wait when='start'> 5 </wait>
   <wait when='stop'> 3 </wait>
</ensure>

[Tobias-Fischer]

Hi @apaikan, did you start working on this? Would be a great feature to have :)

[apaikan]

@Tobias-Fischer just started 🙈
Let see if i can manage to do it by today :)

[Tobias-Fischer]

Great to hear, thanks a lot :). I'm happy to help implementing / try / test if you want, just let me know.

[apaikan]

@pattacini and @Tobias-Fischer

I have just commited. Please let me know who do u feel about that before closing the issue.

For the following application the behavior of the manager would be :

• stop
  1. at time zero user presses the stop button
  2. at time 10 the yarpview receives stop signal
  3. at time 15 the test_grabber receives stop signal

While this behavior seems logical for me, as we have for now, our starting process does not seems to be very useful especially in the following scenario:

• start
  1. at time zero user presses the run button and both of the modules immediately get executed!
  2. at time 5 the the yarpmanager is marked as run in the GUI
  3. at time 10 the test_grabber is marked as run in the GUI

Actually, as it is for now, the start wait does not imply any order in the execution of modules. It is only useful in automatic module execution (as it has been used in RTF fixture manager) to delay running test cases!!!

<application>
    <name>test</name>
    <module>
        <name>test_grabber</name>
        <node>localhost</node>
        <deployer>yarpdev</deployer>
	<ensure>	   
	   <wait when="start"> 10 </wait>
	   <wait when='stop'> 15 </wait>
	</ensure>
    </module>

    <module>
        <name>yarpview</name>
        <node>localhost</node>
	<ensure>	   
	   <wait> 5 </wait>
	   <wait when='stop'> 10 </wait>
	</ensure>
    </module>
</application>

[Tobias-Fischer]

Thanks a lot @apaikan :). This will come in very, very handy.
Regarding the start behavior: The current behavior sounds like a bug to me. I would expect a delay of X seconds before the module is being started. The delayed mark as run makes it even worse, as the user probably thinks the module hasn't launched yet although it actually did.

Best and thanks a lot, Tobi

[pattacini]

@Tobias-Fischer as @apaikan was saying the wait/start is mainly used within the testing framework with the aim described.

There aren't many applications where it is useful indeed.