orogen and typelib updated on orocos-toolchain master

There are some small issues, as orogen's deployments + MQ transport
requires MR#11 to be merged on RTT. Other than that, the test suite
passes *and* orogen works fine for a big bunch of modules.

I'll be glad if typegen users could test it.

Sylvain

orogen and typelib updated on orocos-toolchain master

On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
> There are some small issues, as orogen's deployments + MQ transport
> requires MR#11 to be merged on RTT. Other than that, the test suite
> passes *and* orogen works fine for a big bunch of modules.

Regarding MR#11: why did you introduce readNewest() ? What's the difference
with using a 'data' connection + read() instead of 'buffered' connection +
readNewest() ?

Peter

orogen and typelib updated on orocos-toolchain master

On 11/30/2010 09:00 PM, Peter Soetens wrote:
> On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
>> There are some small issues, as orogen's deployments + MQ transport
>> requires MR#11 to be merged on RTT. Other than that, the test suite
>> passes *and* orogen works fine for a big bunch of modules.
>
> Regarding MR#11: why did you introduce readNewest() ? What's the difference
> with using a 'data' connection + read() instead of 'buffered' connection +
> readNewest() ?
None, and I am not sure it is a good thing ...

The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
between 'data' and 'buffer' connections, to the point where I was
personally not very sure of what was *still* the point of both.

I thought about it yesterday evening, and I am definitely not sure that
readNewest is a good thing. The idea about it appeared while we were
porting our components. The question was "how to be sure that the
component is gonna behave right, regardless of the connection policy
which is being used". The point is that if a data triggered component
that does

if (_port.read(value) == RTT::NewData)
{
}

assuming that the connection will be a data connection, then -- when
connected with a buffered connection, will have a high latency on the port.

As I said, really not sure. So there are two ways to see it: introduce
it and see what happens, or don't. I don't mind either way as the
supervision layer is creating the connection types for me ;-)

orogen and typelib updated on orocos-toolchain master

On Wednesday 01 December 2010 11:12:04 Sylvain Joyeux wrote:
> On 11/30/2010 09:00 PM, Peter Soetens wrote:
> > On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
> >> There are some small issues, as orogen's deployments + MQ transport
> >> requires MR#11 to be merged on RTT. Other than that, the test suite
> >> passes *and* orogen works fine for a big bunch of modules.
> >
> > Regarding MR#11: why did you introduce readNewest() ? What's the
> > difference with using a 'data' connection + read() instead of 'buffered'
> > connection + readNewest() ?
>
> None, and I am not sure it is a good thing ...
>
> The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
> between 'data' and 'buffer' connections, to the point where I was
> personally not very sure of what was *still* the point of both.
>
> I thought about it yesterday evening, and I am definitely not sure that
> readNewest is a good thing. The idea about it appeared while we were
> porting our components. The question was "how to be sure that the
> component is gonna behave right, regardless of the connection policy
> which is being used". The point is that if a data triggered component
> that does
>
> if (_port.read(value) == RTT::NewData)
> {
> }
>
> assuming that the connection will be a data connection, then -- when
> connected with a buffered connection, will have a high latency on the port.

You know the component shouldn't assume anything about the connection policy
:-)

>
> As I said, really not sure. So there are two ways to see it: introduce
> it and see what happens, or don't. I don't mind either way as the
> supervision layer is creating the connection types for me ;-)

Sorry for the delay on the MR. I want to merge it today asap. I personally
don't like components making these 'flush' decisions, since they are making
system level decisions. For example, they don't produce one output for each
input. When you're going to hardware, that's probably not an issue, and
omitting readNewest from the API won't stop users from implementing this tiny
loop themselves.

Any one else an opinion on this ?

Peter

orogen and typelib updated on orocos-toolchain master

On 12/06/2010 11:31 AM, Peter Soetens wrote:
> On Wednesday 01 December 2010 11:12:04 Sylvain Joyeux wrote:
>> On 11/30/2010 09:00 PM, Peter Soetens wrote:
>>> On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
>>>> There are some small issues, as orogen's deployments + MQ transport
>>>> requires MR#11 to be merged on RTT. Other than that, the test suite
>>>> passes *and* orogen works fine for a big bunch of modules.
>>>
>>> Regarding MR#11: why did you introduce readNewest() ? What's the
>>> difference with using a 'data' connection + read() instead of 'buffered'
>>> connection + readNewest() ?
>>
>> None, and I am not sure it is a good thing ...
>>
>> The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
>> between 'data' and 'buffer' connections, to the point where I was
>> personally not very sure of what was *still* the point of both.
>>
>> I thought about it yesterday evening, and I am definitely not sure that
>> readNewest is a good thing. The idea about it appeared while we were
>> porting our components. The question was "how to be sure that the
>> component is gonna behave right, regardless of the connection policy
>> which is being used". The point is that if a data triggered component
>> that does
>>
>> if (_port.read(value) == RTT::NewData)
>> {
>> }
>>
>> assuming that the connection will be a data connection, then -- when
>> connected with a buffered connection, will have a high latency on the port.
>
> You know the component shouldn't assume anything about the connection policy
> :-)
>
>>
>> As I said, really not sure. So there are two ways to see it: introduce
>> it and see what happens, or don't. I don't mind either way as the
>> supervision layer is creating the connection types for me ;-)
>
> Sorry for the delay on the MR. I want to merge it today asap. I personally
> don't like components making these 'flush' decisions, since they are making
> system level decisions. For example, they don't produce one output for each
> input. When you're going to hardware, that's probably not an issue, and
> omitting readNewest from the API won't stop users from implementing this tiny
> loop themselves.
In principle, I agree with you that everything should be properly
stream-aligned on timestamps and then produce multiple outputs for each
input and so on ...

Except that in practice, it requires a lot of overhead on the part of
the component developer, and therefore is seldom done.

orogen and typelib updated on orocos-toolchain master

On Mon, 6 Dec 2010, Peter Soetens wrote:

> On Wednesday 01 December 2010 11:12:04 Sylvain Joyeux wrote:
>> On 11/30/2010 09:00 PM, Peter Soetens wrote:
>>> On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
>>>> There are some small issues, as orogen's deployments + MQ transport
>>>> requires MR#11 to be merged on RTT. Other than that, the test suite
>>>> passes *and* orogen works fine for a big bunch of modules.
>>>
>>> Regarding MR#11: why did you introduce readNewest() ? What's the
>>> difference with using a 'data' connection + read() instead of 'buffered'
>>> connection + readNewest() ?
>>
>> None, and I am not sure it is a good thing ...
>>
>> The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
>> between 'data' and 'buffer' connections, to the point where I was
>> personally not very sure of what was *still* the point of both.
>>
>> I thought about it yesterday evening, and I am definitely not sure that
>> readNewest is a good thing. The idea about it appeared while we were
>> porting our components. The question was "how to be sure that the
>> component is gonna behave right, regardless of the connection policy
>> which is being used". The point is that if a data triggered component
>> that does
>>
>> if (_port.read(value) == RTT::NewData)
>> {
>> }
>>
>> assuming that the connection will be a data connection, then -- when
>> connected with a buffered connection, will have a high latency on the port.
>
> You know the component shouldn't assume anything about the connection policy
> :-)
>
>>
>> As I said, really not sure. So there are two ways to see it: introduce
>> it and see what happens, or don't. I don't mind either way as the
>> supervision layer is creating the connection types for me ;-)
>
> Sorry for the delay on the MR. I want to merge it today asap. I personally
> don't like components making these 'flush' decisions, since they are making
> system level decisions. For example, they don't produce one output for each
> input. When you're going to hardware, that's probably not an issue, and
> omitting readNewest from the API won't stop users from implementing this tiny
> loop themselves.
>
> Any one else an opinion on this ?

What is "this" exactly?

> Peter

Herman

orogen and typelib updated on orocos-toolchain master

On Monday 06 December 2010 11:41:48 Herman Bruyninckx wrote:
> On Mon, 6 Dec 2010, Peter Soetens wrote:
> > On Wednesday 01 December 2010 11:12:04 Sylvain Joyeux wrote:
> >> On 11/30/2010 09:00 PM, Peter Soetens wrote:
> >>> On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
> >>>> There are some small issues, as orogen's deployments + MQ transport
> >>>> requires MR#11 to be merged on RTT. Other than that, the test suite
> >>>> passes *and* orogen works fine for a big bunch of modules.
> >>>
> >>> Regarding MR#11: why did you introduce readNewest() ? What's the
> >>> difference with using a 'data' connection + read() instead of
> >>> 'buffered' connection + readNewest() ?
> >>
> >> None, and I am not sure it is a good thing ...
> >>
> >> The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
> >> between 'data' and 'buffer' connections, to the point where I was
> >> personally not very sure of what was *still* the point of both.
> >>
> >> I thought about it yesterday evening, and I am definitely not sure that
> >> readNewest is a good thing. The idea about it appeared while we were
> >> porting our components. The question was "how to be sure that the
> >> component is gonna behave right, regardless of the connection policy
> >> which is being used". The point is that if a data triggered component
> >> that does
> >>
> >> if (_port.read(value) == RTT::NewData)
> >> {
> >> }
> >>
> >> assuming that the connection will be a data connection, then -- when
> >> connected with a buffered connection, will have a high latency on the
> >> port.
> >
> > You know the component shouldn't assume anything about the connection
> > policy
> >
> > :-)
> > :
> >> As I said, really not sure. So there are two ways to see it: introduce
> >> it and see what happens, or don't. I don't mind either way as the
> >> supervision layer is creating the connection types for me ;-)
> >
> > Sorry for the delay on the MR. I want to merge it today asap. I
> > personally don't like components making these 'flush' decisions, since
> > they are making system level decisions. For example, they don't produce
> > one output for each input. When you're going to hardware, that's
> > probably not an issue, and omitting readNewest from the API won't stop
> > users from implementing this tiny loop themselves.
> >
> > Any one else an opinion on this ?
>
> What is "this" exactly?

If the 'readNewest()' function should be added to the API of an input port, as
the Merge Request nbr #12 proposes.
http://gitorious.org/orocos-toolchain/rtt/merge_requests/12

Peter

orogen and typelib updated on orocos-toolchain master

On Mon, 6 Dec 2010, Peter Soetens wrote:

> On Monday 06 December 2010 11:41:48 Herman Bruyninckx wrote:
>> On Mon, 6 Dec 2010, Peter Soetens wrote:
>>> On Wednesday 01 December 2010 11:12:04 Sylvain Joyeux wrote:
>>>> On 11/30/2010 09:00 PM, Peter Soetens wrote:
>>>>> On Tuesday 30 November 2010 18:31:49 Sylvain Joyeux wrote:
>>>>>> There are some small issues, as orogen's deployments + MQ transport
>>>>>> requires MR#11 to be merged on RTT. Other than that, the test suite
>>>>>> passes *and* orogen works fine for a big bunch of modules.
>>>>>
>>>>> Regarding MR#11: why did you introduce readNewest() ? What's the
>>>>> difference with using a 'data' connection + read() instead of
>>>>> 'buffered' connection + readNewest() ?
>>>>
>>>> None, and I am not sure it is a good thing ...
>>>>
>>>> The RTT::OldData/RTT::NewData thing, in effect, blurred the difference
>>>> between 'data' and 'buffer' connections, to the point where I was
>>>> personally not very sure of what was *still* the point of both.
>>>>
>>>> I thought about it yesterday evening, and I am definitely not sure that
>>>> readNewest is a good thing. The idea about it appeared while we were
>>>> porting our components. The question was "how to be sure that the
>>>> component is gonna behave right, regardless of the connection policy
>>>> which is being used". The point is that if a data triggered component
>>>> that does
>>>>
>>>> if (_port.read(value) == RTT::NewData)
>>>> {
>>>> }
>>>>
>>>> assuming that the connection will be a data connection, then -- when
>>>> connected with a buffered connection, will have a high latency on the
>>>> port.
>>>
>>> You know the component shouldn't assume anything about the connection
>>> policy
>>>
>>> :-)
>>> :
>>>> As I said, really not sure. So there are two ways to see it: introduce
>>>> it and see what happens, or don't. I don't mind either way as the
>>>> supervision layer is creating the connection types for me ;-)
>>>
>>> Sorry for the delay on the MR. I want to merge it today asap. I
>>> personally don't like components making these 'flush' decisions, since
>>> they are making system level decisions. For example, they don't produce
>>> one output for each input. When you're going to hardware, that's
>>> probably not an issue, and omitting readNewest from the API won't stop
>>> users from implementing this tiny loop themselves.
>>>
>>> Any one else an opinion on this ?
>>
>> What is "this" exactly?
>
> If the 'readNewest()' function should be added to the API of an input port, as
> the Merge Request nbr #12 proposes.
> http://gitorious.org/orocos-toolchain/rtt/merge_requests/12

Ok, thanks for this information. I think this is not a good feature to add:
the policy of what to do with buffered samples should not be implemented in
the inputport functionality of a component; it belongs in the buffering
code of the communication components.

Informing the inputting component about whether or not a data sample has
already been input before does make sense for that component. But it should
cost it no extra computational efforts compared to a "uninformed" read.

> Peter

Herman