Hi guys,
I have defined a requested operation in my component using the following
syntax:
this->requires("ttrk")->addOperationCaller(this->sendCommandToCICAS);
where the OperationCaller is defined by:
RTT::OperationCaller< int (CICAS_TC) > sendCommandToCICAS;
Is there a way to manipulate the OperationCaller in scripting (my component
is executing a StateMachine periodically)?
I found nothing from the documentation, so I fear it is not possible...
Is there a possible workaround (s.t. defining an Operation that calls the
Operation caller)?
Would it be difficult to integrate such a skill to the Scripting?
Thanks in advance,
Charles.
Calling an OperationCaller from scripting
Hi Charles,
On Mon, Feb 13, 2012 at 11:18 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:
> Hi guys,
>
> I have defined a requested operation in my component using the following
> syntax:
>
>
> this->requires("ttrk")->addOperationCaller(this->sendCommandToCICAS);
>
> where the OperationCaller is defined by:
> RTT::OperationCaller< int (CICAS_TC) > sendCommandToCICAS;
>
>
> Is there a way to manipulate the OperationCaller in scripting (my
> component is executing a StateMachine periodically)?
>
That's a bit ironic :-) The OperationCaller is (roughly) the C++ equivalent
of what you do in scripting, ie, 'late binding'. In other words, we had in
mind to use it in C++ only, hence there were no scripting bindings.
>
> I found nothing from the documentation, so I fear it is not possible...
>
> Is there a possible workaround (s.t. defining an Operation that calls the
> Operation caller)?
>
Well, in scripting, you can define an 'alias' which will execute the
aliased 'expression', but that won't allow you to add arguments (unless you
use attributes as arguments which you fill in before invoking the alias).
That's all a bit hacky imho.
>
> Would it be difficult to integrate such a skill to the Scripting?
>
Hmm. What you'd need is quite intrusive:
* let the operation parsing also iterate over the 'requires' interfaces to
find a match
* Then look up the real operation behind it and find its 'part' factory (so
the OperationCaller needs to cache that pointer).
* Use that part factory to continue as usual
If the OperationCaller is not yet connected, this mechanism can not work,
and the script parsing will fail.
I don't see any reasonable way to start creating part factories for
OperationCallers themselves.
Peter
Calling an OperationCaller from scripting
Hi Charles,
On Mon, Feb 13, 2012 at 11:18 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:
> Hi guys,
>
> I have defined a requested operation in my component using the following
> syntax:
>
>
> this->requires("ttrk")->addOperationCaller(this->sendCommandToCICAS);
>
> where the OperationCaller is defined by:
> RTT::OperationCaller< int (CICAS_TC) > sendCommandToCICAS;
>
>
> Is there a way to manipulate the OperationCaller in scripting (my
> component is executing a StateMachine periodically)?
>
That's a bit ironic :-) The OperationCaller is (roughly) the C++ equivalent
of what you do in scripting, ie, 'late binding'. In other words, we had in
mind to use it in C++ only, hence there were no scripting bindings.
>
> I found nothing from the documentation, so I fear it is not possible...
>
> Is there a possible workaround (s.t. defining an Operation that calls the
> Operation caller)?
>
Well, in scripting, you can define an 'alias' which will execute the
aliased 'expression', but that won't allow you to add arguments (unless you
use attributes as arguments which you fill in before invoking the alias).
That's all a bit hacky imho.
>
> Would it be difficult to integrate such a skill to the Scripting?
>
Hmm. What you'd need is quite intrusive:
* let the operation parsing also iterate over the 'requires' interfaces to
find a match
* Then look up the real operation behind it and find its 'part' factory (so
the OperationCaller needs to cache that pointer).
* Use that part factory to continue as usual
If the OperationCaller is not yet connected, this mechanism can not work,
and the script parsing will fail.
I don't see any reasonable way to start creating part factories for
OperationCallers themselves.
Peter
Calling an OperationCaller from scripting
2012/2/14 Peter Soetens <peter [..] ...>
> Hi Charles,
>
> On Mon, Feb 13, 2012 at 11:18 AM, Charles Lesire-Cabaniols <
> charles [dot] lesire [..] ...> wrote:
>
>> Hi guys,
>>
>> I have defined a requested operation in my component using the following
>> syntax:
>>
>>
>> this->requires("ttrk")->addOperationCaller(this->sendCommandToCICAS);
>>
>> where the OperationCaller is defined by:
>> RTT::OperationCaller< int (CICAS_TC) > sendCommandToCICAS;
>>
>>
>> Is there a way to manipulate the OperationCaller in scripting (my
>> component is executing a StateMachine periodically)?
>>
>
> That's a bit ironic :-) The OperationCaller is (roughly) the C++
> equivalent of what you do in scripting, ie, 'late binding'. In other words,
> we had in mind to use it in C++ only, hence there were no scripting
> bindings.
>
In practice, I have a component that requires that 'ttrk' service. In the
deployer (and then in scripting) I cannot manipulate ttrk.sendCommand
directly, but I have to use the name of the peer that provides this
service. This makes my script dependent on the name of another component,
whereas my C++ code is not! Which is not 'symmetric'...
>
>
>>
>> I found nothing from the documentation, so I fear it is not possible...
>>
>> Is there a possible workaround (s.t. defining an Operation that calls the
>> Operation caller)?
>>
>
> Well, in scripting, you can define an 'alias' which will execute the
> aliased 'expression', but that won't allow you to add arguments (unless you
> use attributes as arguments which you fill in before invoking the alias).
> That's all a bit hacky imho.
>
And I cannot figure out how to use it concretely. Could you give an example?
>
>
>>
>> Would it be difficult to integrate such a skill to the Scripting?
>>
>
> Hmm. What you'd need is quite intrusive:
> * let the operation parsing also iterate over the 'requires' interfaces to
> find a match
> * Then look up the real operation behind it and find its 'part' factory
> (so the OperationCaller needs to cache that pointer).
> * Use that part factory to continue as usual
>
It's maybe the best solution, as I definitely cannot use the 'provider'
component name in my 'requiring' component script.
I will try to look deeped into this solution.
>
> If the OperationCaller is not yet connected, this mechanism can not work,
> and the script parsing will fail.
>
> I don't see any reasonable way to start creating part factories for
> OperationCallers themselves.
>
> Peter
>
>
Calling an OperationCaller from scripting
2012/2/14 Peter Soetens <peter [..] ...>
> Hi Charles,
>
> On Mon, Feb 13, 2012 at 11:18 AM, Charles Lesire-Cabaniols <
> charles [dot] lesire [..] ...> wrote:
>
>> Hi guys,
>>
>> I have defined a requested operation in my component using the following
>> syntax:
>>
>>
>> this->requires("ttrk")->addOperationCaller(this->sendCommandToCICAS);
>>
>> where the OperationCaller is defined by:
>> RTT::OperationCaller< int (CICAS_TC) > sendCommandToCICAS;
>>
>>
>> Is there a way to manipulate the OperationCaller in scripting (my
>> component is executing a StateMachine periodically)?
>>
>
> That's a bit ironic :-) The OperationCaller is (roughly) the C++
> equivalent of what you do in scripting, ie, 'late binding'. In other words,
> we had in mind to use it in C++ only, hence there were no scripting
> bindings.
>
In practice, I have a component that requires that 'ttrk' service. In the
deployer (and then in scripting) I cannot manipulate ttrk.sendCommand
directly, but I have to use the name of the peer that provides this
service. This makes my script dependent on the name of another component,
whereas my C++ code is not! Which is not 'symmetric'...
>
>
>>
>> I found nothing from the documentation, so I fear it is not possible...
>>
>> Is there a possible workaround (s.t. defining an Operation that calls the
>> Operation caller)?
>>
>
> Well, in scripting, you can define an 'alias' which will execute the
> aliased 'expression', but that won't allow you to add arguments (unless you
> use attributes as arguments which you fill in before invoking the alias).
> That's all a bit hacky imho.
>
And I cannot figure out how to use it concretely. Could you give an example?
>
>
>>
>> Would it be difficult to integrate such a skill to the Scripting?
>>
>
> Hmm. What you'd need is quite intrusive:
> * let the operation parsing also iterate over the 'requires' interfaces to
> find a match
> * Then look up the real operation behind it and find its 'part' factory
> (so the OperationCaller needs to cache that pointer).
> * Use that part factory to continue as usual
>
It's maybe the best solution, as I definitely cannot use the 'provider'
component name in my 'requiring' component script.
I will try to look deeped into this solution.
>
> If the OperationCaller is not yet connected, this mechanism can not work,
> and the script parsing will fail.
>
> I don't see any reasonable way to start creating part factories for
> OperationCallers themselves.
>
> Peter
>
>
Calling an OperationCaller from scripting
On Wed, Feb 15, 2012 at 10:38 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:
>
>
> 2012/2/14 Peter Soetens <peter [..] ...>
>
>> Hi Charles,
>>
>> On Mon, Feb 13, 2012 at 11:18 AM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>> Hi guys,
>>>
>>> I have defined a requested operation in my component using the following
>>> syntax:
>>>
>>>
>>> this->requires("ttrk")->addOperationCaller(this->sendCommandToCICAS);
>>>
>>> where the OperationCaller is defined by:
>>> RTT::OperationCaller< int (CICAS_TC) > sendCommandToCICAS;
>>>
>>>
>>> Is there a way to manipulate the OperationCaller in scripting (my
>>> component is executing a StateMachine periodically)?
>>>
>>
>> That's a bit ironic :-) The OperationCaller is (roughly) the C++
>> equivalent of what you do in scripting, ie, 'late binding'. In other words,
>> we had in mind to use it in C++ only, hence there were no scripting
>> bindings.
>>
>
>
> In practice, I have a component that requires that 'ttrk' service. In the
> deployer (and then in scripting) I cannot manipulate ttrk.sendCommand
> directly, but I have to use the name of the peer that provides this
> service. This makes my script dependent on the name of another component,
> whereas my C++ code is not! Which is not 'symmetric'...
>
I understand.
>
>
>>
>>
>>>
>>> I found nothing from the documentation, so I fear it is not possible...
>>>
>>> Is there a possible workaround (s.t. defining an Operation that calls
>>> the Operation caller)?
>>>
>>
>> Well, in scripting, you can define an 'alias' which will execute the
>> aliased 'expression', but that won't allow you to add arguments (unless you
>> use attributes as arguments which you fill in before invoking the alias).
>> That's all a bit hacky imho.
>>
>
> And I cannot figure out how to use it concretely. Could you give an
> example?
>
The alias defines a new attribute/variable which evaluates an expression.
There's a bug in the taskbrowser such that you can't use it directly in the
taskbrowser, but you could write in your script:
alias bool r = task.isRunning();
if ( r ) { ... }
>
>
>>
>>
>>>
>>> Would it be difficult to integrate such a skill to the Scripting?
>>>
>>
>> Hmm. What you'd need is quite intrusive:
>> * let the operation parsing also iterate over the 'requires' interfaces
>> to find a match
>> * Then look up the real operation behind it and find its 'part' factory
>> (so the OperationCaller needs to cache that pointer).
>> * Use that part factory to continue as usual
>>
>
> It's maybe the best solution, as I definitely cannot use the 'provider'
> component name in my 'requiring' component script.
> I will try to look deeped into this solution.
>
>
>>
>> If the OperationCaller is not yet connected, this mechanism can not work,
>> and the script parsing will fail.
>>
>> I don't see any reasonable way to start creating part factories for
>> OperationCallers themselves.
>>
>> Peter
>>
>>
>
Peter
Calling an OperationCaller from scripting
On Wed, Feb 15, 2012 at 10:38 AM, Charles Lesire-Cabaniols <
charles [dot] lesire [..] ...> wrote:
>
>
> 2012/2/14 Peter Soetens <peter [..] ...>
>
>> Hi Charles,
>>
>> On Mon, Feb 13, 2012 at 11:18 AM, Charles Lesire-Cabaniols <
>> charles [dot] lesire [..] ...> wrote:
>>
>>> Hi guys,
>>>
>>> I have defined a requested operation in my component using the following
>>> syntax:
>>>
>>>
>>> this->requires("ttrk")->addOperationCaller(this->sendCommandToCICAS);
>>>
>>> where the OperationCaller is defined by:
>>> RTT::OperationCaller< int (CICAS_TC) > sendCommandToCICAS;
>>>
>>>
>>> Is there a way to manipulate the OperationCaller in scripting (my
>>> component is executing a StateMachine periodically)?
>>>
>>
>> That's a bit ironic :-) The OperationCaller is (roughly) the C++
>> equivalent of what you do in scripting, ie, 'late binding'. In other words,
>> we had in mind to use it in C++ only, hence there were no scripting
>> bindings.
>>
>
>
> In practice, I have a component that requires that 'ttrk' service. In the
> deployer (and then in scripting) I cannot manipulate ttrk.sendCommand
> directly, but I have to use the name of the peer that provides this
> service. This makes my script dependent on the name of another component,
> whereas my C++ code is not! Which is not 'symmetric'...
>
I understand.
>
>
>>
>>
>>>
>>> I found nothing from the documentation, so I fear it is not possible...
>>>
>>> Is there a possible workaround (s.t. defining an Operation that calls
>>> the Operation caller)?
>>>
>>
>> Well, in scripting, you can define an 'alias' which will execute the
>> aliased 'expression', but that won't allow you to add arguments (unless you
>> use attributes as arguments which you fill in before invoking the alias).
>> That's all a bit hacky imho.
>>
>
> And I cannot figure out how to use it concretely. Could you give an
> example?
>
The alias defines a new attribute/variable which evaluates an expression.
There's a bug in the taskbrowser such that you can't use it directly in the
taskbrowser, but you could write in your script:
alias bool r = task.isRunning();
if ( r ) { ... }
>
>
>>
>>
>>>
>>> Would it be difficult to integrate such a skill to the Scripting?
>>>
>>
>> Hmm. What you'd need is quite intrusive:
>> * let the operation parsing also iterate over the 'requires' interfaces
>> to find a match
>> * Then look up the real operation behind it and find its 'part' factory
>> (so the OperationCaller needs to cache that pointer).
>> * Use that part factory to continue as usual
>>
>
> It's maybe the best solution, as I definitely cannot use the 'provider'
> component name in my 'requiring' component script.
> I will try to look deeped into this solution.
>
>
>>
>> If the OperationCaller is not yet connected, this mechanism can not work,
>> and the script parsing will fail.
>>
>> I don't see any reasonable way to start creating part factories for
>> OperationCallers themselves.
>>
>> Peter
>>
>>
>
Peter