In relation to this: OROMACS I have been working on a refactoring of TaskCore; details see my personal gitorious clone (vri-rtt).
My intentions:
- to (if possible) make minimal changes from the perspective of the OROCOS application/component builder; the API of classes used by the end user should change as little as possible. It works well as it is right now
- to have abstract base classes that define the interface and from which I can derive an alternative implementation of TaskCore, for the extensions we have developed.
The thing that I wish to change is the states defined in TaskCore. Hence, I have introduced an abstract class TaskCoreInterface that has pure virtual functions for the state transitions.
Furthermore, I have isolated the execution-engine related functionality in another base class, in the spirit of having classes with single responsibilities. Not so important, probably.
As a next step, I intend to refactor TaskContext in the same spirit.
I am not as experienced in C++ as you guys, so bear with me please if I make stupid proposals.
Comments welcome!
Cheers, Theo.
refactoring of TaskCore
On Wed, 9 Feb 2011, t [dot] j [dot] a [dot] devries [..] ... wrote:
> In relation to this: [http://www.orocos.org/forum/rtt/rtt-dev/orocos-toolchain-22-broken-win32#comment-29990 OROMACS] I have been working on a refactoring of TaskCore; details see my personal gitorious clone (vri-rtt).
>
> My intentions:
> # to (if possible) make minimal changes from the perspective of the OROCOS application/component builder; the API of classes used by the end user should change as little as possible. It works well as it is right now
> # to have abstract base classes that define the interface and from which I can derive an alternative implementation of TaskCore, for the extensions we have developed.
>
> The thing that I wish to change is the states defined in TaskCore. Hence, I have introduced an abstract class TaskCoreInterface that has pure virtual functions for the state transitions.
Thanks for the efforts! I do like to first have a discussion about the
_motivations_ behind these efforts: why exactly are your efforts useful for
Orocos? what better decoupling than what we have now do they bring? what
use cases do they support (better)? Etc.
> Furthermore, I have isolated the execution-engine related functionality
> in another base class, in the spirit of having classes with single
> responsibilities. Not so important, probably.
If this is a further step towards better 'separation of concerns', it _is_
important :-)
> As a next step, I intend to refactor TaskContext in the same spirit.
>
> I am not as experienced in C++ as you guys, so bear with me please if I make stupid proposals.
>
> Comments welcome!
>
> Cheers, Theo.
Herman
refactoring of TaskCore
Fair enough.
I have no clear picture of what might be in development at Leuven, but as I see it now an RTT app consists of a network of components, where each component may or may not be a separate thread or be distributed. Something very valuable! It results in a program that has a part-of hierarchy of 2 levels deep: the network layer and the layer with individual components. What I would like to add is to be able to define the computation inside a component in terms of a network of sub-components again, etc. I.e., in the spirit of Simulink / 20-sim; the app can consist of a part-of hierarchy of arbitrary depth. This has been raised in earlier discussions. I hope that the use case for this is clear to you.
Hence, a component can then be a composition of subcomponents. As the subcomponents may have different states at a single moment in time, one of the implications is that the state of a composition needs to be defined. The current implementation of TaskCore has not been considered from this perspective.
My personal view is that the transition interfaces that are now present are fine, but that:
Comments please... :-)
cheers, Theo
hmm, I did not succeed in attaching the pic; I am editing on the site, and it gives me the next error: "File upload error. Could not move uploaded file." ???
refactoring of TaskCore
On 02/10/2011 09:16 AM, t [dot] j [dot] a [dot] devries [..] ... wrote:
> Fair enough.
>
> I have no clear picture of what might be in development at Leuven, but as I see it now an RTT app consists of a network of components, where each component may or may not be a separate thread or be distributed. Something very valuable! It results in a program that has a part-of hierarchy of 2 levels deep: the network layer and the layer with individual components.
> What I would like to add is to be able to define the computation inside a component in terms of a network of sub-components again, etc. I.e., in the spirit of Simulink / 20-sim; the app can consist of a part-of hierarchy of arbitrary depth. This has been raised in earlier discussions. I hope that the use case for this is clear to you.
> Hence, a component can then be a composition of subcomponents. As the subcomponents may have different states at a single moment in time, one of the implications is that the state of a composition needs to be defined. The current implementation of TaskCore has not been considered from this perspective.
While I do see the usefulness of composition of components, I am
wondering what complexity it introduces to make these compositions
subclasses of TaskCore.
What does it bring ? Couldn't the compositions be a separate class
hierarchy ? I personally think that RTT is already very complex and that
we should avoid adding new layers unless really necessary.
Moreover, as you say it yourself, compositions are different beasts from
a monitoring point of view (completely different state machine and
handling), so why make them "yet another component" ?
> My personal view is that the transition interfaces that are now present are fine, but that:
> # we need more/different states. Specifically, I would like to split the running state in an 'operational' state, in which actual output calculation is done, and an 'idle' state, in which state variables are refreshed but actual output calculation is not done. See the attached STD
I do see the interest in that, but from a different perspective: it
would allow to monitor how long a component takes to compute ...
refactoring of TaskCore
On Thu, 10 Feb 2011, Sylvain Joyeux wrote:
> On 02/10/2011 09:16 AM, t [dot] j [dot] a [dot] devries [..] ... wrote:
>> Fair enough.
>>
>> I have no clear picture of what might be in development at Leuven, but as I see it now an RTT app consists of a network of components, where each component may or may not be a separate thread or be distributed. Something very valuable! It results in a program that has a part-of hierarchy of 2 levels deep: the network layer and the layer with individual components.
>> What I would like to add is to be able to define the computation inside a component in terms of a network of sub-components again, etc. I.e., in the spirit of Simulink / 20-sim; the app can consist of a part-of hierarchy of arbitrary depth. This has been raised in earlier discussions. I hope that the use case for this is clear to you.
>> Hence, a component can then be a composition of subcomponents. As the subcomponents may have different states at a single moment in time, one of the implications is that the state of a composition needs to be defined. The current implementation of TaskCore has not been considered from this perspective.
>
> While I do see the usefulness of composition of components, I am
> wondering what complexity it introduces to make these compositions
> subclasses of TaskCore.
>
> What does it bring ? Couldn't the compositions be a separate class
> hierarchy ? I personally think that RTT is already very complex and that
> we should avoid adding new layers unless really necessary.
>
> Moreover, as you say it yourself, compositions are different beasts from
> a monitoring point of view (completely different state machine and
> handling), so why make them "yet another component" ?
Valid remarks...
My view on this "compositionality" problem is as follows:
- there _is_ a need for composing functional building blocks into larger
hierarchies, and to reuse such a larger hierarchy as a new, first-class
component.
- it is true that the current 2.X RTT design is not really good wrt this
compositionality aspect.
- there _is_ a need for a "systems and control library" in Orocos, whose
_functionality_ supports the use cases that Theo mentions: bond graph or
control diagram composition of primitive "computations", with some
"coordination" around it.
- there is a need for _tooling_ (and less so for new features within RTT)
to suppport the code generation from a "component-based drawing of a
complex control system" to a deployable set of binaries. One of the major
missing tools is to let the application builder decide whether Ports have
to be translated into middleware communication stubs (in case of really
distributed deployment), or just to shared memory (in case of in-process
deployment).
- the important part of this discussion is: which of the suggested
'refactoring' or 'patches' are relevant for RTT, and which are relevant
for the to-be-introduced "SCL".
My gut feeling for the time being is that your contributions are _only_
SCL- and tooling-related. Which is fine! :-)
>> My personal view is that the transition interfaces that are now present
>> are fine, but that:
>> # we need more/different states. Specifically, I would like to split the
>> running state in an 'operational' state, in which actual output
>> calculation is done, and an 'idle' state, in which state variables are
>> refreshed but actual output calculation is not done. See the attached
>> STD
> I do see the interest in that, but from a different perspective: it
> would allow to monitor how long a component takes to compute ...
These 'extra states' make sense, _but_:
- its the _application_ that has to introduce them (and that can be done
now already, without any problem)
- we should only allow an extension of RTT to include more "native" states
if its is very clear that _every_ application would profit from them
- the currently native states have gone through such a review process, but
that was years ago, and it might be time to redo it
- the motivation for the currently present states was for RTT to suppor the
_lifetime_ of a component, irrespective of what the component is _doing_.
And personally, I would like to keep it that way, that is, a clear
separation between "infrastructural states" (= every application _needs_
them), and "application states" (= make sense in a particular application
domain
refactoring of TaskCore
On 02/10/2011 09:57 AM, Herman Bruyninckx wrote:
> My view on this "compositionality" problem is as follows:
> - there _is_ a need for composing functional building blocks into larger
> hierarchies, and to reuse such a larger hierarchy as a new, first-class
> component.
> - it is true that the current 2.X RTT design is not really good wrt this
> compositionality aspect.
> - there _is_ a need for a "systems and control library" in Orocos, whose
> _functionality_ supports the use cases that Theo mentions: bond
> graph or
> control diagram composition of primitive "computations", with some
> "coordination" around it.
> - there is a need for _tooling_ (and less so for new features within RTT)
> to suppport the code generation from a "component-based drawing of a
> complex control system" to a deployable set of binaries. One of the
> major
> missing tools is to let the application builder decide whether Ports
> have
> to be translated into middleware communication stubs (in case of really
> distributed deployment), or just to shared memory (in case of
> in-process
> deployment).
> - the important part of this discussion is: which of the suggested
> 'refactoring' or 'patches' are relevant for RTT, and which are relevant
> for the to-be-introduced "SCL".
> My gut feeling for the time being is that your contributions are _only_
> SCL- and tooling-related. Which is fine! :-)
For the record, there is already tooling for compositions / system
deployment and management. It is in rock, and -- more importantly -- it
is built OUTSIDE the rtt. I personally believe that it is its place
(regardless of the programming language and deployment paradigm), and
that we should keep that stuff out of the RTT as much as possible.
>>> My personal view is that the transition interfaces that are now present
>>> are fine, but that:
>>> # we need more/different states. Specifically, I would like to split
>>> the
>>> running state in an 'operational' state, in which actual output
>>> calculation is done, and an 'idle' state, in which state variables are
>>> refreshed but actual output calculation is not done. See the attached
>>> STD
>> I do see the interest in that, but from a different perspective: it
>> would allow to monitor how long a component takes to compute ...
>
> These 'extra states' make sense, _but_:
> - its the _application_ that has to introduce them (and that can be done
> now already, without any problem)
> - we should only allow an extension of RTT to include more "native"
> states
> if its is very clear that _every_ application would profit from them
> - the currently native states have gone through such a review process,
> but
> that was years ago, and it might be time to redo it
> - the motivation for the currently present states was for RTT to
> suppor the
> _lifetime_ of a component, irrespective of what the component is
> _doing_.
> And personally, I would like to keep it that way, that is, a clear
> separation between "infrastructural states" (= every application
> _needs_
> them), and "application states" (= make sense in a particular
> application
> domain
Agreed.
refactoring of TaskCore
On Thu, 10 Feb 2011, Sylvain Joyeux wrote:
> On 02/10/2011 09:57 AM, Herman Bruyninckx wrote:
>> My view on this "compositionality" problem is as follows:
>> - there _is_ a need for composing functional building blocks into larger
>> hierarchies, and to reuse such a larger hierarchy as a new, first-class
>> component.
>> - it is true that the current 2.X RTT design is not really good wrt this
>> compositionality aspect.
>> - there _is_ a need for a "systems and control library" in Orocos, whose
>> _functionality_ supports the use cases that Theo mentions: bond
>> graph or
>> control diagram composition of primitive "computations", with some
>> "coordination" around it.
>> - there is a need for _tooling_ (and less so for new features within RTT)
>> to suppport the code generation from a "component-based drawing of a
>> complex control system" to a deployable set of binaries. One of the
>> major
>> missing tools is to let the application builder decide whether Ports
>> have
>> to be translated into middleware communication stubs (in case of really
>> distributed deployment), or just to shared memory (in case of
>> in-process
>> deployment).
>> - the important part of this discussion is: which of the suggested
>> 'refactoring' or 'patches' are relevant for RTT, and which are relevant
>> for the to-be-introduced "SCL".
>> My gut feeling for the time being is that your contributions are _only_
>> SCL- and tooling-related. Which is fine! :-)
> For the record, there is already tooling for compositions / system
> deployment and management. It is in rock, and -- more importantly -- it
> is built OUTSIDE the rtt. I personally believe that it is its place
> (regardless of the programming language and deployment paradigm), and
> that we should keep that stuff out of the RTT as much as possible.
I agree! "Keep outside" but "make interoperable" is a key strategy in the
context of complex systems design, development and deployment.
>>>> My personal view is that the transition interfaces that are now present
>>>> are fine, but that:
>>>> # we need more/different states. Specifically, I would like to split
>>>> the
>>>> running state in an 'operational' state, in which actual output
>>>> calculation is done, and an 'idle' state, in which state variables are
>>>> refreshed but actual output calculation is not done. See the attached
>>>> STD
>>> I do see the interest in that, but from a different perspective: it
>>> would allow to monitor how long a component takes to compute ...
>>
>> These 'extra states' make sense, _but_:
>> - its the _application_ that has to introduce them (and that can be done
>> now already, without any problem)
>> - we should only allow an extension of RTT to include more "native"
>> states
>> if its is very clear that _every_ application would profit from them
>> - the currently native states have gone through such a review process,
>> but
>> that was years ago, and it might be time to redo it
>> - the motivation for the currently present states was for RTT to
>> suppor the
>> _lifetime_ of a component, irrespective of what the component is
>> _doing_.
>> And personally, I would like to keep it that way, that is, a clear
>> separation between "infrastructural states" (= every application
>> _needs_
>> them), and "application states" (= make sense in a particular
>> application
>> domain
> Agreed.
> Sylvain Joyeux
Herman
Re: refactoring of TaskCore
> On 02/10/2011 09:57 AM, Herman Bruyninckx wrote: >> My view on this "compositionality" problem is as follows: >> - there _is_ a need for composing functional building blocks into larger >> hierarchies, and to reuse such a larger hierarchy as a new, first-class >> component. >> - it is true that the current 2.X RTT design is not really good wrt this >> compositionality aspect. >> - there _is_ a need for a "systems and control library" in Orocos, whose >> _functionality_ supports the use cases that Theo mentions: bond >> graph or >> control diagram composition of primitive "computations", with some >> "coordination" around it. >> - there is a need for _tooling_ (and less so for new features within RTT) >> to suppport the code generation from a "component-based drawing of a >> complex control system" to a deployable set of binaries. One of the >> major >> missing tools is to let the application builder decide whether Ports >> have >> to be translated into middleware communication stubs (in case of really >> distributed deployment), or just to shared memory (in case of >> in-process >> deployment). >> - the important part of this discussion is: which of the suggested >> 'refactoring' or 'patches' are relevant for RTT, and which are relevant >> for the to-be-introduced "SCL". >> My gut feeling for the time being is that your contributions are _only_ >> SCL- and tooling-related. Which is fine! :-) > For the record, there is already tooling for compositions / system > deployment and management. It is in rock, and -- more importantly -- it > is built OUTSIDE the rtt. I personally believe that it is its place > (regardless of the programming language and deployment paradigm), and > that we should keep that stuff out of the RTT as much as possible.
I agree! "Keep outside" but "make interoperable" is a key strategy in the context of complex systems design, development and deployment.
>>>> My personal view is that the transition interfaces that are now present >>>> are fine, but that: >>>> # we need more/different states. Specifically, I would like to split >>>> the >>>> running state in an 'operational' state, in which actual output >>>> calculation is done, and an 'idle' state, in which state variables are >>>> refreshed but actual output calculation is not done. See the attached >>>> STD >>> I do see the interest in that, but from a different perspective: it >>> would allow to monitor how long a component takes to compute ... >> >> These 'extra states' make sense, _but_: >> - its the _application_ that has to introduce them (and that can be done >> now already, without any problem) >> - we should only allow an extension of RTT to include more "native" >> states >> if its is very clear that _every_ application would profit from them >> - the currently native states have gone through such a review process, >> but >> that was years ago, and it might be time to redo it >> - the motivation for the currently present states was for RTT to >> suppor the >> _lifetime_ of a component, irrespective of what the component is >> _doing_. >> And personally, I would like to keep it that way, that is, a clear >> separation between "infrastructural states" (= every application >> _needs_ >> them), and "application states" (= make sense in a particular >> application >> domain > Agreed.
> Sylvain Joyeux
Herman
I think we all agree. As I tried to stress before, my intention is to not modify RTT. The only thing I did was refactoring TaskCore (and TaskContext, that is yet to be put on gitorious) for the purpose of being able to subclass it OUTSIDE of RTT. Indeed precisely as Herman puts it: to have an extension of RTT that has more native states, but adheres to the TaskCore interface. And indeed, Sylvian is right, one can debate whether it is wise to let these "SCL components" derive from TaskCore(Interface). We have decided to indeed let them derive from TaskCoreInterface, but let us not discuss that here. The point is whether you want to make it possible to do so or not.
I agree with Sylvian that keeping RTT as simple as possible and clean is important. However, I object to the statement that the refactored TaskCore adds complexity, just because of the extra layer in the hierarchy. The resulting classes themselves are cleaner and easier to understand.
With hesitation, I also put forward the next point. The hesitation comes from the fact that I have high appreciation for the design(ers) of OROCOS and I have learned a lot from studying it (and still learning!). With respect to the current design of TaskCore, I feel that the refactored version is a little bit better. The current TaskCore has a dual role: it is a base class for TaskContext, and it implements the functionality of a primitive OROCOS component. If we split it into TaskCoreInterface and an implementation class, we can more easily promote people to implement extensions against the interface and not depend on the current implementation. This would e.g. facilitate future reconsideration of the implemented states.
Cheers, Theo.
refactoring of TaskCore
On Thu, 10 Feb 2011, t [dot] j [dot] a [dot] devries [..] ... wrote:
>
>
>> On 02/10/2011 09:57 AM, Herman Bruyninckx wrote:
>>> My view on this "compositionality" problem is as follows:
>>> - there _is_ a need for composing functional building blocks into larger
>>> hierarchies, and to reuse such a larger hierarchy as a new, first-class
>>> component.
>>> - it is true that the current 2.X RTT design is not really good wrt this
>>> compositionality aspect.
>>> - there _is_ a need for a "systems and control library" in Orocos, whose
>>> _functionality_ supports the use cases that Theo mentions: bond
>>> graph or
>>> control diagram composition of primitive "computations", with some
>>> "coordination" around it.
>>> - there is a need for _tooling_ (and less so for new features within RTT)
>>> to suppport the code generation from a "component-based drawing of a
>>> complex control system" to a deployable set of binaries. One of the
>>> major
>>> missing tools is to let the application builder decide whether Ports
>>> have
>>> to be translated into middleware communication stubs (in case of really
>>> distributed deployment), or just to shared memory (in case of
>>> in-process
>>> deployment).
>>> - the important part of this discussion is: which of the suggested
>>> 'refactoring' or 'patches' are relevant for RTT, and which are relevant
>>> for the to-be-introduced "SCL".
>>> My gut feeling for the time being is that your contributions are _only_
>>> SCL- and tooling-related. Which is fine! :-)
>> For the record, there is already tooling for compositions / system
>> deployment and management. It is in rock, and -- more importantly -- it
>> is built OUTSIDE the rtt. I personally believe that it is its place
>> (regardless of the programming language and deployment paradigm), and
>> that we should keep that stuff out of the RTT as much as possible.
>
> I agree! "Keep outside" but "make interoperable" is a key strategy in the
> context of complex systems design, development and deployment.
>
>>>>> My personal view is that the transition interfaces that are now present
>>>>> are fine, but that:
>>>>> # we need more/different states. Specifically, I would like to split
>>>>> the
>>>>> running state in an 'operational' state, in which actual output
>>>>> calculation is done, and an 'idle' state, in which state variables are
>>>>> refreshed but actual output calculation is not done. See the attached
>>>>> STD
>>>> I do see the interest in that, but from a different perspective: it
>>>> would allow to monitor how long a component takes to compute ...
>>>
>>> These 'extra states' make sense, _but_:
>>> - its the _application_ that has to introduce them (and that can be done
>>> now already, without any problem)
>>> - we should only allow an extension of RTT to include more "native"
>>> states
>>> if its is very clear that _every_ application would profit from them
>>> - the currently native states have gone through such a review process,
>>> but
>>> that was years ago, and it might be time to redo it
>>> - the motivation for the currently present states was for RTT to
>>> suppor the
>>> _lifetime_ of a component, irrespective of what the component is
>>> _doing_.
>>> And personally, I would like to keep it that way, that is, a clear
>>> separation between "infrastructural states" (= every application
>>> _needs_
>>> them), and "application states" (= make sense in a particular
>>> application
>>> domain
>> Agreed.
>
>> Sylvain Joyeux
>
> Herman
>
>
> I think we all agree.
> As I tried to stress before, my intention is to not modify RTT. The only thing I did was refactoring TaskCore (and TaskContext, that is yet to be put on gitorious) for the purpose of being able to subclass it OUTSIDE of RTT. Indeed precisely as Herman puts it: to have an extension of RTT that has more native states, but adheres to the TaskCore interface. And indeed, Sylvian is right, one can debate whether it is wise to let these "SCL components" derive from TaskCore(Interface).
> We have decided to indeed let them derive from TaskCoreInterface, but let
> us not discuss that here.
Where else? :-)
> The point is whether you want to make it possible to do so or not.
To make _what_ possible exactly? The _functionality_, or the sub-class
derivation?
> I agree with Sylvian that keeping RTT as simple as possible and clean is
> important. However, I object to the statement that the refactored
> TaskCore adds complexity,
It was not a statement, but rather a concern: we have not seen concrete
enough designs yet to make such strong statements ;-)
> just because of the extra layer in the hierarchy. The resulting classes
> themselves are cleaner and easier to understand.
That's a very subjective statement :-) But I am ready to be convinced, of
course.
> With hesitation, I also put forward the next point. The hesitation comes
> from the fact that I have high appreciation for the design(ers) of OROCOS
> and I have learned a lot from studying it (and still learning!).
Open source is not about (not) hurting the feelings of co-developers :-)
So, don't hesitate! Strong criticism is the only way to learn...
> With
> respect to the current design of TaskCore, I feel that the refactored
> version is a little bit better.
If you can turn your feeling into refurable arguments, I would be very happy. :-)
> The current TaskCore has a dual role: it
> is a base class for TaskContext, and it implements the functionality of a
> primitive OROCOS component. If we split it into TaskCoreInterface and an
> implementation class, we can more easily promote people to implement
> extensions against the interface and not depend on the current
> implementation. This would e.g. facilitate future reconsideration of the
> implemented states.
I do not yet fully understand what you mean exactly, but I feel that there
is some "5C decoupling" stuff in what you write, and that always makes me
happy! I am _quite sure_ our current designs need some decoupling
refactoring, so please don't hesitate, and shoot at us with the concrete
suggestions you have in mind, or have already implemented.
> Cheers, Theo.
Herman
refactoring of TaskCore
> I do not yet fully understand what you mean exactly, but I feel that there
> is some "5C decoupling" stuff in what you write, and that always makes me
> happy! I am _quite sure_ our current designs need some decoupling
> refactoring, so please don't hesitate, and shoot at us with the concrete
> suggestions you have in mind, or have already implemented.
>
Slightly OT. May I ask what is the fifth C?. It's the first time I read
about it and you got me curious :)
Apologies for the intrusion in this thread,
Adolfo
refactoring of TaskCore
I think the fifth C is Connection.
I got a question about 5C during the defense :)
2011/2/10 Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...>
>
> I do not yet fully understand what you mean exactly, but I feel that there
>> is some "5C decoupling" stuff in what you write, and that always makes me
>> happy! I am _quite sure_ our current designs need some decoupling
>> refactoring, so please don't hesitate, and shoot at us with the concrete
>> suggestions you have in mind, or have already implemented.
>>
>
> Slightly OT. May I ask what is the fifth C?. It's the first time I read
> about it and you got me curious :)
>
> Apologies for the intrusion in this thread,
>
> Adolfo
>
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited. If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
refactoring of TaskCore
On Thu, 10 Feb 2011, Dao Ba Phong wrote:
> I think the fifth C is Connection.
> I got a question about 5C during the defense :)
I should not discuss my ideas too much on public mailinglists, but first
work on publications :-)
Herman
> 2011/2/10 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>
>
> I do not yet fully understand what you mean exactly, but
> I feel that there
> is some "5C decoupling" stuff in what you write, and
> that always makes me
> happy! I am _quite sure_ our current designs need some
> decoupling
> refactoring, so please don't hesitate, and shoot at us
> with the concrete
> suggestions you have in mind, or have already
> implemented.
>
>
> Slightly OT. May I ask what is the fifth C?. It's the first time I read
> about it and you got me curious :)
>
> Apologies for the intrusion in this thread,
>
> Adolfo
>
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited. If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
refactoring of TaskCore
2011/2/10 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>
> On Thu, 10 Feb 2011, Dao Ba Phong wrote:
>
> I think the fifth C is Connection.
>> I got a question about 5C during the defense :)
>>
>
> I should not discuss my ideas too much on public mailinglists, but first
> work on publications :-)
>
I appreciate the sneak preview :)
Adolfo
> Herman
>
>
> 2011/2/10 Adolfo Rodríguez Tsouroukdissian <
>> adolfo [dot] rodriguez [..] ...>
>>
>> I do not yet fully understand what you mean exactly, but
>> I feel that there
>> is some "5C decoupling" stuff in what you write, and
>> that always makes me
>> happy! I am _quite sure_ our current designs need some
>> decoupling
>> refactoring, so please don't hesitate, and shoot at us
>> with the concrete
>> suggestions you have in mind, or have already
>> implemented.
>>
>>
>> Slightly OT. May I ask what is the fifth C?. It's the first time I read
>> about it and you got me curious :)
>>
>> Apologies for the intrusion in this thread,
>>
>> Adolfo
>>
>> --
>> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>>
>> Robotics engineer
>> PAL ROBOTICS S.L
>> http://www.pal-robotics.com
>> Tel. +34.93.414.53.47
>> Fax.+34.93.209.11.09
>>
>> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
>> contain confidential information which is privileged and intended only for
>> the individual or entity to whom they are addressed. If you are not the
>> intended recipient, you are hereby notified that any disclosure, copying,
>> distribution or use of this e-mail and/or accompanying document(s) is
>> strictly prohibited. If you have received this e-mail in error, please
>> immediately notify the sender at the above e-mail address.
>>
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>>
>>
>>
> --
> K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
> <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
> EURON Coordinator (European Robotics Research Network) <
> http://www.euron.org>
> Open Realtime Control Services <http://www.orocos.org>
> Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
>
refactoring of TaskCore
On Thu, 10 Feb 2011, Adolfo Rodríguez Tsouroukdissian wrote:
>
> I do not yet fully understand what you mean exactly, but I feel that
> there
> is some "5C decoupling" stuff in what you write, and that always
> makes me
> happy! I am _quite sure_ our current designs need some decoupling
> refactoring, so please don't hesitate, and shoot at us with the
> concrete
> suggestions you have in mind, or have already implemented.
>
>
> Slightly OT. May I ask what is the fifth C?. It's the first time I read about it
> and you got me curious :)
>
> Apologies for the intrusion in this thread,
No problem!
Since a couple of months, I have split the "Configuration" C of Radestock
and Eisenbach's 1996 paper into:
- "Connectivity", being all the infrastructure, parameters, "knowledge",...
related to how to best interconnect components, and
- "Configuration", being all the infrastructure and code to best select the
concrete values for all configurable properties of components.
This version of "Configuration" is "cross-sectional" to the other Cs
since Computation, Coordination, Communication and Connectivity all have
properties that need optimal configuration.
> Adolfo
Herman
> --
> Adolfo Rodríguez Tsouroukdissian, Ph. D.
>
> Robotics engineer
> PAL ROBOTICS S.L
> http://www.pal-robotics.com
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may contain
> confidential information which is privileged and intended only for the
> individual or entity to whom they are addressed. If you are not the intended
> recipient, you are hereby notified that any disclosure, copying, distribution or
> use of this e-mail and/or accompanying document(s) is strictly prohibited. If
> you have received this e-mail in error, please immediately notify the sender at
> the above e-mail address.
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>