Hi,
I am trying to use rttlib.mappeers function to have my 'supervisor'
component configure all its (unconfigured) peers when it is itself
configured.
I faced a strange behavior when doing supervisor:configure(), observing
some repeated configuration steps.
Actually, the issue comes from the fact that when I call
rttlib.mappeers(func, tc), the 'func' function is applied to tc's peers,
but also to tc itself!
Maybe this was the desired behavior when implementing the function, but I
think this is a bug, as the function is 'mappeers', and not 'mapmeandpeers'
;)
Charles.
[RTT-Lua] mappers behavior
2012/7/19 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
> Hi,
>
> I am trying to use rttlib.mappeers function to have my 'supervisor'
> component configure all its (unconfigured) peers when it is itself
> configured.
> I faced a strange behavior when doing supervisor:configure(), observing
> some repeated configuration steps.
>
> Actually, the issue comes from the fact that when I call
> rttlib.mappeers(func, tc), the 'func' function is applied to tc's peers,
> but also to tc itself!
>
Moreover, the 'func' function is also recursively applied to the peers of
the tc's peers, and so on.
Application of func to tc actually comes from the implementation of this
recursive behavior I guess.
So maybe introducing a 'rttlib.recursive_mappeers' function could be a good
idea if this recursive behavior is needed on a specific use-case (even if I
can't imagine one where it could be a good practice to have 'func' be
applied to components I don't even know they exist!)
>
> Maybe this was the desired behavior when implementing the function, but I
> think this is a bug, as the function is 'mappeers', and not 'mapmeandpeers'
> ;)
>
> Charles.
>
[RTT-Lua] mappers behavior
Hi Charles,
On Thu, Jul 19, 2012 at 11:35:53AM +0200, Charles Lesire-Cabaniols wrote:
>
>
> 2012/7/19 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
>
> Hi,
>
> I am trying to use rttlib.mappeers function to have my 'supervisor'
> component configure all its (unconfigured) peers when it is itself
> configured.
> I faced a strange behavior when doing supervisor:configure(), observing
> some repeated configuration steps.
>
> Actually, the issue comes from the fact that when I call rttlib.mappeers
> (func, tc), the 'func' function is applied to tc's peers, but also to tc
> itself!
>
>
> Moreover, the 'func' function is also recursively applied to the peers of the
> tc's peers, and so on.
> Application of func to tc actually comes from the implementation of this
> recursive behavior I guess.
You are right!
> So maybe introducing a 'rttlib.recursive_mappeers' function could be a good
> idea if this recursive behavior is needed on a specific use-case (even if I
> can't imagine one where it could be a good practice to have 'func' be applied
> to components I don't even know they exist!)
It depends on whether you view peers as a list or a tree :-) When I
wrote it I had the latter in mind, and yes, this is very useful if you
want to do something with all peers, such as the validation example in
the cookbook. Instead of splitting the function into two, I would
prefer an optional depth parameter that permits specifying how deep
the traversal shall take place. For instance 'mapfsm' in rfsm.lua does
it that way. Then you could pass the value 1 to only apply func to you
immediate peers.
Would that be acceptable?
Markus
[RTT-Lua] mappers behavior
2012/7/31 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
> Hi Charles,
>
> On Thu, Jul 19, 2012 at 11:35:53AM +0200, Charles Lesire-Cabaniols wrote:
> >
> >
> > 2012/7/19 Charles Lesire-Cabaniols <charles [dot] lesire [..] ...>
> >
> > Hi,
> >
> > I am trying to use rttlib.mappeers function to have my 'supervisor'
> > component configure all its (unconfigured) peers when it is itself
> > configured.
> > I faced a strange behavior when doing supervisor:configure(),
> observing
> > some repeated configuration steps.
> >
> > Actually, the issue comes from the fact that when I call
> rttlib.mappeers
> > (func, tc), the 'func' function is applied to tc's peers, but also
> to tc
> > itself!
> >
> >
> > Moreover, the 'func' function is also recursively applied to the peers
> of the
> > tc's peers, and so on.
> > Application of func to tc actually comes from the implementation of this
> > recursive behavior I guess.
>
> You are right!
>
> > So maybe introducing a 'rttlib.recursive_mappeers' function could be a
> good
> > idea if this recursive behavior is needed on a specific use-case (even
> if I
> > can't imagine one where it could be a good practice to have 'func' be
> applied
> > to components I don't even know they exist!)
>
> It depends on whether you view peers as a list or a tree :-) When I
> wrote it I had the latter in mind, and yes, this is very useful if you
> want to do something with all peers, such as the validation example in
>
the cookbook. Instead of splitting the function into two, I would
> prefer an optional depth parameter that permits specifying how deep
> the traversal shall take place. For instance 'mapfsm' in rfsm.lua does
> it that way. Then you could pass the value 1 to only apply func to you
> immediate peers.
>
> Would that be acceptable?
>
Perfect
>
> Markus
>
>
>