This is a request for comment (and again sorry for the spam before).
The following patches define two Activity subclasses which I found quite
useful:
* the FileDescriptorActivity which steps() when data is available on a
file descriptor. Very handy to implement a sensor driver which waits
for the sensor's data stream, while keeping the ability to control
the TaskContext object (i.e. stop(), error states, ...)
* the IRQActivity (Xenomai-specific) which steps() when an IRQ is
detected. I personally use that to read timestamps that are provided
on one pin of the parallel port.
Any comments on the implementation and the general usefulness of these
would be greatly appreciated.
[RFC] specialized Activity subclasses
On Thursday 25 September 2008 19:01:50 Sylvain Joyeux wrote:
> This is a request for comment (and again sorry for the spam before).
>
> The following patches define two Activity subclasses which I found quite
> useful:
>
> * the FileDescriptorActivity which steps() when data is available on a
> file descriptor. Very handy to implement a sensor driver which waits
> for the sensor's data stream, while keeping the ability to control
> the TaskContext object (i.e. stop(), error states, ...)
> * the IRQActivity (Xenomai-specific) which steps() when an IRQ is
> detected. I personally use that to read timestamps that are provided
> on one pin of the parallel port.
>
> Any comments on the implementation and the general usefulness of these
> would be greatly appreciated.
I'm in favor of giving such contributions a proper place. Since they are and have the implementation in liborocos-ocl-common.so
application specific, they belong 'somewhere' in the OCL. Proposals for
the 'new' (if required) subdirectory are welcome. We could just let it
install in
I don't want these things in ocl as 'second class' citizens, so I'm opposed to path. The same holds for Ruben's ublas
putting them in an
toolkit. It must get a proper place, although toolkits go by definition in
their own library.
Peter
[RFC] specialized Activity subclasses
On Fri, Oct 17, 2008 at 04:04:42PM +0200, Peter Soetens wrote: and have the implementation in liborocos-ocl-common.so
> On Thursday 25 September 2008 19:01:50 Sylvain Joyeux wrote:
> > This is a request for comment (and again sorry for the spam before).
> >
> > The following patches define two Activity subclasses which I found quite
> > useful:
> >
> > * the FileDescriptorActivity which steps() when data is available on a
> > file descriptor. Very handy to implement a sensor driver which waits
> > for the sensor's data stream, while keeping the ability to control
> > the TaskContext object (i.e. stop(), error states, ...)
> > * the IRQActivity (Xenomai-specific) which steps() when an IRQ is
> > detected. I personally use that to read timestamps that are provided
> > on one pin of the parallel port.
> >
> > Any comments on the implementation and the general usefulness of these
> > would be greatly appreciated.
>
> I'm in favor of giving such contributions a proper place. Since they are
> application specific, they belong 'somewhere' in the OCL. Proposals for
> the 'new' (if required) subdirectory are welcome. We could just let it
> install in
This really, in my opinion, belongs to Orocos/RTT. These are not
components ('O' in OCL) and are "generally useful" for the "general" use
of RTT. Personally, I would never have searched them in OCL -- where
finding something is somewhat difficult by the way.
Summary: I'm more in favor of having it in a special place in RTT. I
really REALLY personally dislike OCL. I basically only use TaskBrowser
from here --- and even that will drop RealTimeSoon(tm) since I'm finally
having my ruby/corba scripting library ready.
Sylvain
[RFC] specialized Activity subclasses
On Thursday 25 September 2008 19:01:50 Sylvain Joyeux wrote:
> This is a request for comment (and again sorry for the spam before).
>
> The following patches define two Activity subclasses which I found quite
> useful:
I'm reviewing your patches, but it would make my job easier if you constructed
them as 'single, logical change' based rather than 'historical change' based.
Maybe you do this for the ease of svn-to-git integration ? From my pov, the
FileDescriptorActivity and the IRQActivity could have been two patches just
adding these classes. Now I have to apply all your patches and then look at
the resulting diff to see the end result at once.
More comments follow later...
Peter
>
> * the FileDescriptorActivity which steps() when data is available on a
> file descriptor. Very handy to implement a sensor driver which waits
> for the sensor's data stream, while keeping the ability to control
> the TaskContext object (i.e. stop(), error states, ...)
> * the IRQActivity (Xenomai-specific) which steps() when an IRQ is
> detected. I personally use that to read timestamps that are provided
> on one pin of the parallel port.
>
> Any comments on the implementation and the general usefulness of these
> would be greatly appreciated.
> --
> =======================================================================
> Dr. Ing. Sylvain Joyeux sylvain [dot] joyeux [..] ...
> Researcher
> DFKI Robotik Lab -- Bremen http://www.dfki.de/robotik
> Tel: 0049 421 218 64136
> =======================================================================
[RFC] specialized Activity subclasses
On Mon, Sep 29, 2008 at 05:33:51PM +0200, Peter Soetens wrote:
> On Thursday 25 September 2008 19:01:50 Sylvain Joyeux wrote:
> > This is a request for comment (and again sorry for the spam before).
> >
> > The following patches define two Activity subclasses which I found quite
> > useful:
>
> I'm reviewing your patches, but it would make my job easier if you constructed
> them as 'single, logical change' based rather than 'historical change' based.
> Maybe you do this for the ease of svn-to-git integration ?
I do this because they reflect my development history, yes.
> From my pov, the FileDescriptorActivity and the IRQActivity could have
> been two patches just adding these classes. Now I have to apply all
> your patches and then look at the resulting diff to see the end result
> at once.
Mmmm ... I'll refactor those. I did not want to do this, because for me
some "tricky" parts of the activity development are now reflected into
the development history, meaning that they somehow document why things
are what they are. But still, I can refactor the patch list anyway.
[RFC] specialized Activity subclasses
On Thu, 25 Sep 2008, Sylvain Joyeux wrote:
> This is a request for comment (and again sorry for the spam before).
>
> The following patches define two Activity subclasses which I found quite
> useful:
>
> * the FileDescriptorActivity which steps() when data is available on a
> file descriptor. Very handy to implement a sensor driver which waits
> for the sensor's data stream, while keeping the ability to control
> the TaskContext object (i.e. stop(), error states, ...)
> * the IRQActivity (Xenomai-specific) which steps() when an IRQ is
> detected. I personally use that to read timestamps that are provided
> on one pin of the parallel port.
>
> Any comments on the implementation and the general usefulness of these
> would be greatly appreciated.
Why is there a need to put the _cause_ of the events in the API? This opens
up the road to a bunch of application specific events APIs...
In my opinion, this information is to be given to the system during
configuration/deployment: it's then that you decide what physical cause is
behind an event to which you want your activities to react.
Herman
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
[RFC] specialized Activity subclasses
On Fri, Sep 26, 2008 at 08:03:12AM +0200, Herman Bruyninckx wrote:
> On Thu, 25 Sep 2008, Sylvain Joyeux wrote:
>
>> This is a request for comment (and again sorry for the spam before).
>>
>> The following patches define two Activity subclasses which I found quite
>> useful:
>>
>> * the FileDescriptorActivity which steps() when data is available on a
>> file descriptor. Very handy to implement a sensor driver which waits
>> for the sensor's data stream, while keeping the ability to control
>> the TaskContext object (i.e. stop(), error states, ...)
>> * the IRQActivity (Xenomai-specific) which steps() when an IRQ is
>> detected. I personally use that to read timestamps that are provided
>> on one pin of the parallel port.
>>
>> Any comments on the implementation and the general usefulness of these
>> would be greatly appreciated.
>
> Why is there a need to put the _cause_ of the events in the API? This opens
> up the road to a bunch of application specific events APIs...
You don't put the cause in the API. You can use a TaskContext as a
periodic task *and* as an IRQ-driven task at the same time. What changes
is the chosen subclass of Activity -- i.e. the chosen deployment
options.
> In my opinion, this information is to be given to the system during
> configuration/deployment: it's then that you decide what physical cause is
> behind an event to which you want your activities to react.
That doesn't change anything. You actually need your system to *react*
and for that you need specific implementations -- that can get quite
tricky, thus it is better to share them. There is *already* a few
different Activity subclasses in RTT (periodic, event processors, ...)
so I really don't see your point here.
[RFC] specialized Activity subclasses
On Fri, 26 Sep 2008, Sylvain Joyeux wrote:
> On Fri, Sep 26, 2008 at 08:03:12AM +0200, Herman Bruyninckx wrote:
>> On Thu, 25 Sep 2008, Sylvain Joyeux wrote:
>>
>>> This is a request for comment (and again sorry for the spam before).
>>>
>>> The following patches define two Activity subclasses which I found quite
>>> useful:
>>>
>>> * the FileDescriptorActivity which steps() when data is available on a
>>> file descriptor. Very handy to implement a sensor driver which waits
>>> for the sensor's data stream, while keeping the ability to control
>>> the TaskContext object (i.e. stop(), error states, ...)
>>> * the IRQActivity (Xenomai-specific) which steps() when an IRQ is
>>> detected. I personally use that to read timestamps that are provided
>>> on one pin of the parallel port.
>>>
>>> Any comments on the implementation and the general usefulness of these
>>> would be greatly appreciated.
>>
>> Why is there a need to put the _cause_ of the events in the API? This opens
>> up the road to a bunch of application specific events APIs...
> You don't put the cause in the API. You can use a TaskContext as a
> periodic task *and* as an IRQ-driven task at the same time. What changes
> is the chosen subclass of Activity -- i.e. the chosen deployment
> options.
So, apparently we are talking about the same things: deployment-level
additions?
>> In my opinion, this information is to be given to the system during
>> configuration/deployment: it's then that you decide what physical cause is
>> behind an event to which you want your activities to react.
> That doesn't change anything. You actually need your system to *react*
> and for that you need specific implementations -- that can get quite
> tricky, thus it is better to share them. There is *already* a few
> different Activity subclasses in RTT (periodic, event processors, ...)
> so I really don't see your point here.
I am all about sharing, and I certainly appreciate your efforts, let that
be clear! But you asked for comments, so you get them :-)
"periodic" and "event processing" are very generic things, while
"FileDescriptor" is, in my opinion, already too specific.
Herman
[RFC] specialized Activity subclasses
>>> Why is there a need to put the _cause_ of the events in the API? This opens
>>> up the road to a bunch of application specific events APIs...
>> You don't put the cause in the API. You can use a TaskContext as a
>> periodic task *and* as an IRQ-driven task at the same time. What changes
>> is the chosen subclass of Activity -- i.e. the chosen deployment
>> options.
>
> So, apparently we are talking about the same things: deployment-level
> additions?
Well ... Activities are part of the deployment specification so yes.
(correcting myself: you can't use a TaskContext as a periodic and
IRQ-driven activities *at the same time*. It is either-or. The point is
that the same specific TaskContext can be used as a periodic one in one
deployment and as an IRQ-driven one in another).
>>> In my opinion, this information is to be given to the system during
>>> configuration/deployment: it's then that you decide what physical cause is
>>> behind an event to which you want your activities to react.
>> That doesn't change anything. You actually need your system to *react*
>> and for that you need specific implementations -- that can get quite
>> tricky, thus it is better to share them. There is *already* a few
>> different Activity subclasses in RTT (periodic, event processors, ...)
>> so I really don't see your point here.
>
> I am all about sharing, and I certainly appreciate your efforts, let that
> be clear! But you asked for comments, so you get them :-)
Of course ! But I don't agree so I comment you comments ;-)
> "periodic" and "event processing" are very generic things, while
> "FileDescriptor" is, in my opinion, already too specific.
That is where we don't agree. IO-based activities are very generic
indeed. Actually, all device drivers are more or less IO-based
activities. IRQ-driven activities are much more specific of course, but
see below.
The problem is also to increase the overall usefulness of Orocos::RTT.
It is nice to stay generic, but too generic is completely useless. My
point of view is that it would be nice having Orocos::RTT provide a
library of different activities that are "ready to use", making it more
"plug-and-play". Developing new Activity subclasses is a bit tricky, so
you'd better use those provided with the Orocos/RTT itself.
[RFC] specialized Activity subclasses
On Fri, 26 Sep 2008, Sylvain Joyeux wrote:
[...]
> The problem is also to increase the overall usefulness of Orocos::RTT.
> It is nice to stay generic, but too generic is completely useless. My
> point of view is that it would be nice having Orocos::RTT provide a
> library of different activities that are "ready to use", making it more
> "plug-and-play".
I absolutely agree...
> Developing new Activity subclasses is a bit tricky, so
> you'd better use those provided with the Orocos/RTT itself.
... but that's why we created the OCL sub-project! Those "Orocos Control
Library" is meant to collect proven and ready to use developments.
I do want to keep RTT _completely_ generic and application-neutral; OCL is
all about the opposite: very application-driven and specific.
We do have to do a much better job with the OCL project though...
Herman
[RFC] specialized Activity subclasses
>> Developing new Activity subclasses is a bit tricky, so
>> you'd better use those provided with the Orocos/RTT itself.
>
> ... but that's why we created the OCL sub-project! Those "Orocos Control
> Library" is meant to collect proven and ready to use developments.
>
> I do want to keep RTT _completely_ generic and application-neutral; OCL is
> all about the opposite: very application-driven and specific.
To cut down the discussion. I think you and I agree on the principle, we
simply don't see the "organization" of the project in the same way. I
don't think there is a compelling technical reason for one or the other,
so I guess neither of us will change its mind, regardless of how long
this discussion continues.
IMO, the two proposed activities *are* generic enough to be included in
RTT, you don't think so. Given that you control the project, I guess
I'll have to keep them in my own branch of RTT.
[RFC] specialized Activity subclasses
On Fri, 26 Sep 2008, Sylvain Joyeux wrote:
>>> Developing new Activity subclasses is a bit tricky, so
>>> you'd better use those provided with the Orocos/RTT itself.
>>
>> ... but that's why we created the OCL sub-project! Those "Orocos Control
>> Library" is meant to collect proven and ready to use developments.
>>
>> I do want to keep RTT _completely_ generic and application-neutral; OCL is
>> all about the opposite: very application-driven and specific.
>
> To cut down the discussion. I think you and I agree on the principle, we
> simply don't see the "organization" of the project in the same way. I
> don't think there is a compelling technical reason for one or the other,
> so I guess neither of us will change its mind, regardless of how long
> this discussion continues.
Don't give up too soon! :-) I just want to have a clear view on what
exactly you propose and what the gains and the losses could be.
As I said in the other mail, I now understand your point much better, and
have changed my mind! :-) Such things can happen, and they have happened
frequently in the history of Orocos, just ask Peter and Klaas.:-)
> IMO, the two proposed activities *are* generic enough to be included in
> RTT, you don't think so. Given that you control the project, I guess
> I'll have to keep them in my own branch of RTT.
I prefer to reach a situation where own branches are reduced to a minimum.
Herman
[RFC] specialized Activity subclasses
>> Developing new Activity subclasses is a bit tricky, so
>> you'd better use those provided with the Orocos/RTT itself.
> ... but that's why we created the OCL sub-project! Those "Orocos Control
> Library" is meant to collect proven and ready to use developments.
Nope. This is not about creating a set of components. This is about
providing the basic blocks to *deploy* my own components.
For me, OCL is about "OK, you want to use a SICK so get the OCL-provided
SICK driver". What I propose with those activities is "you want to write
a device driver, so you have a generic activity that can allow you to do
so". Moreover, OCL is and will remain a huge bunch of (sometime very
badly designed) components. Frankly, I want to stay away from OCL as
much as possible.
I personally think that some not-so-generic-but-very-useful classes have
their place in RTT. OCL is the completely-application-specific part,
what I propose is getting RTT to be everything-but-the-very-application-specific.
[RFC] specialized Activity subclasses
On Fri, 26 Sep 2008, Sylvain Joyeux wrote:
>>> Developing new Activity subclasses is a bit tricky, so
>>> you'd better use those provided with the Orocos/RTT itself.
>> ... but that's why we created the OCL sub-project! Those "Orocos Control
>> Library" is meant to collect proven and ready to use developments.
> Nope. This is not about creating a set of components. This is about
> providing the basic blocks to *deploy* my own components.
>
> For me, OCL is about "OK, you want to use a SICK so get the OCL-provided
> SICK driver". What I propose with those activities is "you want to write
> a device driver, so you have a generic activity that can allow you to do
> so". Moreover, OCL is and will remain a huge bunch of (sometime very
> badly designed) components. Frankly, I want to stay away from OCL as
> much as possible.
>
> I personally think that some not-so-generic-but-very-useful classes have
> their place in RTT. OCL is the completely-application-specific part,
> what I propose is getting RTT to be everything-but-the-very-application-specific.
This email has now for me made things very clear, thanks! And I agree with
you that there should be a place for this kind of "templates"....
I do suggest others join the discussion with concrete suggestions about how
to fill this gap most appropriately. At this moment, I think your
suggestion is fine: put such patterns that are fully in the scope of RTT
somewhere visibly in the RTT source tree... A major decision criterion will
be, in my opinion, that adding this to the RTT source tree should not bring
any new dependency. Anyway, I am not the RTT maintainer, so I do not have
the last say in this :-)
Thanks again for your constructive contributions!
Herman
[RFC] specialized Activity subclasses
And now with the patches ... I should maybe go home and do that again
tomorrow ;-)