[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] Maintainers - A go for 2.5.0 ?
From:       Herman.Bruyninckx () mech ! kuleuven ! be (Herman Bruyninckx)
Date:       2011-09-29 6:45:11
Message-ID: alpine.DEB.2.02.1109290843570.22650 () roble
[Download RAW message or body]

On Wed, 28 Sep 2011, Vries, Theo J.A. de [imotec bv] wrote:

> 2011/9/28 Peter Soetens <peter at thesourceworks.com>
>       Theo,
> 
> On Tue, Sep 27, 2011 at 9:01 AM, Vries, Theo J.A. de [imotec bv]
> <t.j.a.devries at imotec.nl> wrote:
> 2011/9/23 Peter Soetens <peter at thesourceworks.com>
>
>       I've been cleaning up RTT/OCL to prepare 2.5.0. I've merged
>       the mk/lua branch
>       into OCL per merge request. I have not pulled anything from
>       rock yet and there
>       are no outstanding merge requests.
>
>       Is there any functionality from rock that should be merged or
>       do we leave that
>       for 2.6 ?
>
>       Peter
>       --
>       Orocos-Dev mailing list
>       Orocos-Dev at lists.mech.kuleuven.be
>       http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
> 
> 
> Peter,
> 
> could you please also apply the patch that I submitted for bug 861?
> 
> 
> I'm not going to apply it yet. It doesn't make sense in the general case. Each
> time your buffer is full and the component is triggered, an undefined number of
> data samples may be dropped, unless you use a rigid architecture that protects
> against this.
> 
> Don't get me wrong, I don't think raising the event each time a new sample
> arrives makes more sense. We know by now that complex buffering strategies need
> to be done by a component instead of in the connection protocol, which should
> be as simple as possible. The alternative to your approach is to trigger only
> if a certain level is exceeded (defaulting to zero, so only trigger from 0 ->1
> element), and you could have your way with having this level set to the buffer
> size. It adds equal complexity as your proposal, but at least allows some
> flexibility...
> 
> I'd really like to hear the general consensus about this, in order to broaden
> my view, before making a decision.
>

Buffering problems need to be handled in a communication component, not in a
Port. That communication component is allowed (urged, even!) to interact
with its connected Ports via events, yes.

> Peter

Herman

> 
> --
> Orocos-Dev mailing list
> Orocos-Dev at lists.mech.kuleuven.be
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
> 
> ok, no problem. If I find the time, I will make a new patch following your latest
> suggestion :-)
> Looking forward to 2.5.0, thanks in advance for your efforts!
> Theo

[prev in list] [next in list] [prev in thread] [next in thread]