The next three weeks, I'll be working on the steps necessary to make
the Real-Time Toolkit ready for improved portability and a better structuring
of the build system and the directory structure. You can read all the details
on the wiki here :
http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup
The git repository is a branch in my current github orocos-rtt repository here:
http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
(see for git instructions: http://www.orocos.org/wiki/rtt/git )
Feel free to comment or ask questions about these items.
I'll try to structure the work as such that most can be back-ported to the RTT
1.x branch (on SVN). It's my hope that other operating systems than
GNU/Linux will already benefit from the work done, and that some of our
current Windows/Mac users in pain get a bit relief before I fully focus on
RTT 2.0-only topics.
Peter
First RTT 2.0 work package starts today.
Would you consider adding "properly splitting between advanced and simple
options in CMake files, and document options" ?. Right now, ccmake and cmake-
gui are a bit too crowded to be useful for my taste, and most "simple" options
are not documented.
But YMMV
First RTT 2.0 work package starts today.
2009/6/3 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>:
> Would you consider adding "properly splitting between advanced and simple
> options in CMake files, and document options" ?. Right now, ccmake and cmake-
> gui are a bit too crowded to be useful for my taste, and most "simple" options
> are not documented.
I'll try to pay attention to it, but concrete suggestions are welcome too :-)
Peter
First RTT 2.0 work package starts today.
On Monday 01 June 2009 23:46:22 Peter Soetens wrote:
> The next three weeks, I'll be working on the steps necessary to make
> the Real-Time Toolkit ready for improved portability and a better
> structuring of the build system and the directory structure. You can read
> all the details on the wiki here :
> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup
> The git repository is a branch in my current github orocos-rtt repository
> here: http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
> (see for git instructions: http://www.orocos.org/wiki/rtt/git )
>
> Feel free to comment or ask questions about these items.
Just one remark: the new data flow branch is based on the RTT 1.8 directory
structure. Do you want to merge it later (i.e. when the new directory
structure could cause a problem) or earlier ?
First RTT 2.0 work package starts today.
> -----Original Message-----
> From: orocos-dev-bounces [..] ... [mailto:orocos-dev-
> bounces [..] ...] On Behalf Of Peter Soetens
> Sent: maandag 1 juni 2009 23:46
> To: Orocos Developers
> Subject: [Orocos-Dev] First RTT 2.0 work package starts today.
>
> The next three weeks, I'll be working on the steps necessary to make
> the Real-Time Toolkit ready for improved portability and a better
> structuring
> of the build system and the directory structure. You can read all the
> details
> on the wiki here :
> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup
> The git repository is a branch in my current github orocos-rtt
repository
> here:
> http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
> (see for git instructions: http://www.orocos.org/wiki/rtt/git )
>
> Feel free to comment or ask questions about these items.
>
> I'll try to structure the work as such that most can be back-ported to
the
> RTT
> 1.x branch (on SVN). It's my hope that other operating systems than
> GNU/Linux will already benefit from the work done, and that some of
our
> current Windows/Mac users in pain get a bit relief before I fully
focus on
> RTT 2.0-only topics.
>
I agree on most topics but I'm missing a few accents I mentioned before.
1.1:
Ok.
1.2:
Very welcome since CMake 2.6 has better cross-compiling support.
1.3:
Ok
1.4:
Sugestion: 1.4.3: An empty fosi implementation to start future ports
from. Both for OS and CPU.
1.5:
... The user can switch between these modes at configuration or
run-time.
In my opinion this should be: The user can switch between these modes at
configuration, run-time _OR_ compile time. Further more it should not
add (much) code to the existing implementation. And I prefer to leave
the 'much ' out of that last sentence.
1.6:
Ok. We use CXX test, doesn't need any runtime library. Very useful on
embedded targets.
1.7:
Ok.
I'm not sure this falls under 'clean up' but I didn't find it in any
other WP:
1.8:
Clean up the default 'LockFree' algorithms. I don't want them to
disappear, I should be made easier to select different policies. Take
the AtomicQueue, for example, is currently holding me back from updating
to 1.8 because of the resource-consuming default lock-free
implementation. So if this isn't fixed I will not be able to use RTT
2.0, _ever_.
Kind regards,
Sander.
First RTT 2.0 work package starts today.
On Tue, Jun 2, 2009 at 15:31, Vandenbroucke Sander
<Sander [dot] Vandenbroucke [..] ...> wrote:
> I agree on most topics but I'm missing a few accents I mentioned before.
>
> 1.1:
> Ok.
>
> 1.2:
> Very welcome since CMake 2.6 has better cross-compiling support.
>
> 1.3:
> Ok
>
> 1.4:
> Sugestion: 1.4.3: An empty fosi implementation to start future ports
> from. Both for OS and CPU.
Something like os/template and os/oro_template ?
>
> 1.5:
> ... The user can switch between these modes at configuration or
> run-time.
> In my opinion this should be: The user can switch between these modes at
> configuration, run-time _OR_ compile time. Further more it should not
> add (much) code to the existing implementation. And I prefer to leave
> the 'much ' out of that last sentence.
I can live with regulating "default to old/new behaviour" with a cmake flag, but
I wouldn't recommend 'normal' users to toggle it.
About the implementation, I thought of merging SingleThread and PeriodicThread
in a 'Thread' class and have PeriodicActivity only exist as a special
case (like in
rtt-extras) The default threaded activity is then plain 'Activity'. So
for the core,
I see code reduction even.
>
> 1.6:
> Ok. We use CXX test, doesn't need any runtime library. Very useful on
> embedded targets.
boost unit testing framework can also be used without a runtime library.
It's a compile time option.
>
> 1.7:
> Ok.
>
> I'm not sure this falls under 'clean up' but I didn't find it in any
> other WP:
>
> 1.8:
> Clean up the default 'LockFree' algorithms. I don't want them to
> disappear, I should be made easier to select different policies. Take
> the AtomicQueue, for example, is currently holding me back from updating
> to 1.8 because of the resource-consuming default lock-free
> implementation. So if this isn't fixed I will not be able to use RTT
> 2.0, _ever_.
I've added it to the wiki.
Peter
First RTT 2.0 work package starts today.
> >
> > 1.4:
> > Sugestion: 1.4.3: An empty fosi implementation to start future ports
> > from. Both for OS and CPU.
>
> Something like os/template and os/oro_template ?
>
Yes.
Sander.
First RTT 2.0 work package starts today.
> About the implementation, I thought of merging SingleThread and
> PeriodicThread in a 'Thread' class and have PeriodicActivity only exist as
> a special case (like in rtt-extras) The default threaded activity is then
> plain 'Activity'. So for the core, I see code reduction even.
I have a problem with having PeriodicActivity in a "rtt-extras" directory.
While periodic activities are specialized activities, they also are a basic
feature of a RTT-like library, and as such are not an "extra" thing.
First RTT 2.0 work package starts today.
On Wed, Jun 3, 2009 at 09:26, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>> About the implementation, I thought of merging SingleThread and
>> PeriodicThread in a 'Thread' class and have PeriodicActivity only exist as
>> a special case (like in rtt-extras) The default threaded activity is then
>> plain 'Activity'. So for the core, I see code reduction even.
> I have a problem with having PeriodicActivity in a "rtt-extras" directory.
> While periodic activities are specialized activities, they also are a basic
> feature of a RTT-like library, and as such are not an "extra" thing.
What I meant is that the way PeriodicActivity does it (by serializing
seamingly unrelated activities in the same thread, given they have same
priority and period ) is a special way, equally special as running
when a certain
IRQ happens.
'Activity' will be a full replacement for PeriodicActivity and
NonPeriodicActivity
from a user/functional point of view,
and allows to switch at any time between these two modes.
Peter
First RTT 2.0 work package starts today.
On Wednesday 03 June 2009 10:34:50 Peter Soetens wrote:
> On Wed, Jun 3, 2009 at 09:26, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> >> About the implementation, I thought of merging SingleThread and
> >> PeriodicThread in a 'Thread' class and have PeriodicActivity only exist
> >> as a special case (like in rtt-extras) The default threaded activity is
> >> then plain 'Activity'. So for the core, I see code reduction even.
> >
> > I have a problem with having PeriodicActivity in a "rtt-extras"
> > directory. While periodic activities are specialized activities, they
> > also are a basic feature of a RTT-like library, and as such are not an
> > "extra" thing.
>
> What I meant is that the way PeriodicActivity does it (by serializing
> seamingly unrelated activities in the same thread, given they have same
> priority and period ) is a special way, equally special as running
> when a certain
> IRQ happens.
> 'Activity' will be a full replacement for PeriodicActivity and
> NonPeriodicActivity
> from a user/functional point of view,
> and allows to switch at any time between these two modes.
Aaahhhh.. OK then, very cool.
But I guess we would need to find a new name for PeriodicActivity, otherwise
that will be very confusing ...
First RTT 2.0 work package starts today.
On Jun 3, 2009, at 04:42 , Sylvain Joyeux wrote:
> On Wednesday 03 June 2009 10:34:50 Peter Soetens wrote:
>> On Wed, Jun 3, 2009 at 09:26, Sylvain Joyeux
>> <sylvain [dot] joyeux [..] ...> wrote:
>>>> About the implementation, I thought of merging SingleThread and
>>>> PeriodicThread in a 'Thread' class and have PeriodicActivity only
>>>> exist
>>>> as a special case (like in rtt-extras) The default threaded
>>>> activity is
>>>> then plain 'Activity'. So for the core, I see code reduction even.
>>>
>>> I have a problem with having PeriodicActivity in a "rtt-extras"
>>> directory. While periodic activities are specialized activities,
>>> they
>>> also are a basic feature of a RTT-like library, and as such are
>>> not an
>>> "extra" thing.
>>
>> What I meant is that the way PeriodicActivity does it (by serializing
>> seamingly unrelated activities in the same thread, given they have
>> same
>> priority and period ) is a special way, equally special as running
>> when a certain
>> IRQ happens.
>> 'Activity' will be a full replacement for PeriodicActivity and
>> NonPeriodicActivity
>> from a user/functional point of view,
>> and allows to switch at any time between these two modes.
>
> Aaahhhh.. OK then, very cool.
>
> But I guess we would need to find a new name for PeriodicActivity,
> otherwise
> that will be very confusing ...
Agreed.
And +1 for the serializing controller being not so special case. It
does have good uses.
S
First RTT 2.0 work package starts today.
On Wed, Jun 3, 2009 at 13:49, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Jun 3, 2009, at 04:42 , Sylvain Joyeux wrote:
>
>> On Wednesday 03 June 2009 10:34:50 Peter Soetens wrote:
>>>
>>> On Wed, Jun 3, 2009 at 09:26, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>> wrote:
>>>>>
>>>>> About the implementation, I thought of merging SingleThread and
>>>>> PeriodicThread in a 'Thread' class and have PeriodicActivity only exist
>>>>> as a special case (like in rtt-extras) The default threaded activity is
>>>>> then plain 'Activity'. So for the core, I see code reduction even.
>>>>
>>>> I have a problem with having PeriodicActivity in a "rtt-extras"
>>>> directory. While periodic activities are specialized activities, they
>>>> also are a basic feature of a RTT-like library, and as such are not an
>>>> "extra" thing.
>>>
>>> What I meant is that the way PeriodicActivity does it (by serializing
>>> seamingly unrelated activities in the same thread, given they have same
>>> priority and period ) is a special way, equally special as running
>>> when a certain
>>> IRQ happens.
>>> 'Activity' will be a full replacement for PeriodicActivity and
>>> NonPeriodicActivity
>>> from a user/functional point of view,
>>> and allows to switch at any time between these two modes.
>>
>> Aaahhhh.. OK then, very cool.
>>
>> But I guess we would need to find a new name for PeriodicActivity,
>> otherwise
>> that will be very confusing ...
>
> Agreed.
>
> And +1 for the serializing controller being not so special case. It does
> have good uses.
The recommended/scalable way is still to use SlaveActivity and make the
serialisation explicit in some 'periodic activity controller' component.
But YMMV.
Peter
First RTT 2.0 work package starts today.
On Jun 3, 2009, at 08:23 , Peter Soetens wrote:
> On Wed, Jun 3, 2009 at 13:49, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Jun 3, 2009, at 04:42 , Sylvain Joyeux wrote:
>>
>>> On Wednesday 03 June 2009 10:34:50 Peter Soetens wrote:
>>>>
>>>> On Wed, Jun 3, 2009 at 09:26, Sylvain Joyeux <sylvain [dot] joyeux [..] ...
>>>> >
>>>> wrote:
>>>>>>
>>>>>> About the implementation, I thought of merging SingleThread and
>>>>>> PeriodicThread in a 'Thread' class and have PeriodicActivity
>>>>>> only exist
>>>>>> as a special case (like in rtt-extras) The default threaded
>>>>>> activity is
>>>>>> then plain 'Activity'. So for the core, I see code reduction
>>>>>> even.
>>>>>
>>>>> I have a problem with having PeriodicActivity in a "rtt-extras"
>>>>> directory. While periodic activities are specialized activities,
>>>>> they
>>>>> also are a basic feature of a RTT-like library, and as such are
>>>>> not an
>>>>> "extra" thing.
>>>>
>>>> What I meant is that the way PeriodicActivity does it (by
>>>> serializing
>>>> seamingly unrelated activities in the same thread, given they
>>>> have same
>>>> priority and period ) is a special way, equally special as running
>>>> when a certain
>>>> IRQ happens.
>>>> 'Activity' will be a full replacement for PeriodicActivity and
>>>> NonPeriodicActivity
>>>> from a user/functional point of view,
>>>> and allows to switch at any time between these two modes.
>>>
>>> Aaahhhh.. OK then, very cool.
>>>
>>> But I guess we would need to find a new name for PeriodicActivity,
>>> otherwise
>>> that will be very confusing ...
>>
>> Agreed.
>>
>> And +1 for the serializing controller being not so special case. It
>> does
>> have good uses.
>
> The recommended/scalable way is still to use SlaveActivity and make
> the
> serialisation explicit in some 'periodic activity controller'
> component.
>
> But YMMV.
As long as we know what happens with the serialized controller, it is
easier for us (now) than introducing another component to explicitly
serialize. I agree that your recommended way is more correct, and less
likely to cause issues.
Steering people away from this approach is a damn good idea. We didn't
realise the side-effects of this until months into development. Not
something new users should be dabbling with.
Stephen
First RTT 2.0 work package starts today.
>
> As long as we know what happens with the serialized controller, it is
> easier for us (now) than introducing another component to explicitly
> serialize. I agree that your recommended way is more correct, and less
> likely to cause issues.
>
> Steering people away from this approach is a damn good idea. We didn't
> realise the side-effects of this until months into development. Not
> something new users should be dabbling with.
> Stephen
What are the issues and side-effects you are talking about?
Sander.
First RTT 2.0 work package starts today.
On Wednesday, June 03, 2009, at 10:07AM, "Vandenbroucke Sander" <Sander [dot] Vandenbroucke [..] ...> wrote:
>
>>
>> As long as we know what happens with the serialized controller, it is
>> easier for us (now) than introducing another component to explicitly
>> serialize. I agree that your recommended way is more correct, and less
>> likely to cause issues.
>>
>> Steering people away from this approach is a damn good idea. We didn't
>> realise the side-effects of this until months into development. Not
>> something new users should be dabbling with.
>> Stephen
>What are the issues and side-effects you are talking about?
The exact ones Peter is trying to avoid. Starting/stopping a component changes the order, the fact that all components of the same priority and scheduler are actually all in the same thread, etc.
S
First RTT 2.0 work package starts today.
> the fact that all components of the same priority and
> scheduler are actually all in the same thread, etc.
You guys see this as a bad thing?
S
First RTT 2.0 work package starts today.
On Jun 4, 2009, at 02:22 , Vandenbroucke Sander wrote:
>
>> the fact that all components of the same priority and
>> scheduler are actually all in the same thread, etc.
> You guys see this as a bad thing?
It can be if the implications are not well understood. I was trying to
get at the fact that until this discussion came up a few weeks ago, we
didn't even know of the situation so could not know the implications.
Otherwise, we actually rely on this "feature" with some systems, as I
believe others do.
S
First RTT 2.0 work package starts today.
> >
> > And +1 for the serializing controller being not so special case. It
does
> > have good uses.
>
> The recommended/scalable way is still to use SlaveActivity and make
the
> serialisation explicit in some 'periodic activity controller'
component.
>
> But YMMV.
>
Yes, by using something like a PeriodicActivity with a pretty name. :-)
Sander
First RTT 2.0 work package starts today.
> From: orocos-dev-bounces [..] ... [mailto:orocos-dev-
> bounces [..] ...] On Behalf Of Peter Soetens
> Sent: woensdag 3 juni 2009 10:35
> To: Sylvain Joyeux
> Cc: orocos-dev [..] ...
> Subject: Re: [Orocos-Dev] First RTT 2.0 work package starts today.
>
> On Wed, Jun 3, 2009 at 09:26, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> wrote:
> >> About the implementation, I thought of merging SingleThread and
> >> PeriodicThread in a 'Thread' class and have PeriodicActivity only
exist
> as
> >> a special case (like in rtt-extras) The default threaded activity
is
> then
> >> plain 'Activity'. So for the core, I see code reduction even.
> > I have a problem with having PeriodicActivity in a "rtt-extras"
> directory.
> > While periodic activities are specialized activities, they also are
a
> basic
> > feature of a RTT-like library, and as such are not an "extra" thing.
>
> What I meant is that the way PeriodicActivity does it (by serializing
> seamingly unrelated activities in the same thread, given they have
same
> priority and period ) is a special way, equally special as running
> when a certain
> IRQ happens.
I don't agree with the serializing being a special case. I see it as an
opportunity to optimize the controller. Serialized components don't need
any thread-safe algorithms when communicating with each other.
Do you mean running Orocos without OS with your second special case?
> 'Activity' will be a full replacement for PeriodicActivity and
> NonPeriodicActivity
> from a user/functional point of view,
> and allows to switch at any time between these two modes.
>
Sander.
First RTT 2.0 work package starts today.
On Wed, Jun 3, 2009 at 12:11, Vandenbroucke Sander
<Sander [dot] Vandenbroucke [..] ...> wrote:
>> What I meant is that the way PeriodicActivity does it (by serializing
>> seamingly unrelated activities in the same thread, given they have
> same
>> priority and period ) is a special way, equally special as running
>> when a certain
>> IRQ happens.
> I don't agree with the serializing being a special case. I see it as an
> opportunity to optimize the controller. Serialized components don't need
> any thread-safe algorithms when communicating with each other.
Yes, but neither do their commands or data ports require these in case they
aren't serialised. The only not thread-safe primitive is the method
(and synchronous event handlers if you dare use them), and assuming they
will never be called in concurrent contexts is an optimisation in itself, which
limits these components to very specific architectures. For example, starting
and stopping components must also be controlled carefully.
We don't encourage users to assume this use case for their components,
unless they know what
they're doing, so being a special case :-)
Either way, rtt/extras is just a subdirectory of the official RTT, not
a separate
package that is doomed to degrade.
> Do you mean running Orocos without OS with your second special case?
No, it's an Activity Sylvain wrote which works under Xenomai. It's
something like
kernel interrupt handler signals semaphore for userland when IRQ happens.
Peter
First RTT 2.0 work package starts today.
> -----Original Message-----
> From: peter [dot] soetens [..] ... [mailto:peter [dot] soetens [..] ...] On
Behalf
> Of Peter Soetens
> Sent: woensdag 3 juni 2009 13:55
> To: Vandenbroucke Sander
> Cc: Orocos Developers
> Subject: Re: [Orocos-Dev] First RTT 2.0 work package starts today.
>
> On Wed, Jun 3, 2009 at 12:11, Vandenbroucke Sander
> <Sander [dot] Vandenbroucke [..] ...> wrote:
> >> What I meant is that the way PeriodicActivity does it (by
serializing
> >> seamingly unrelated activities in the same thread, given they have
> > same
> >> priority and period ) is a special way, equally special as running
> >> when a certain
> >> IRQ happens.
> > I don't agree with the serializing being a special case. I see it as
an
> > opportunity to optimize the controller. Serialized components don't
need
> > any thread-safe algorithms when communicating with each other.
>
> Yes, but neither do their commands or data ports require these in case
> they
Euhm, yes they do. You can't just push data from one thread to an other
without any precaution, you of all people should know this.
> aren't serialised. The only not thread-safe primitive is the method
> (and synchronous event handlers if you dare use them), and assuming
they
> will never be called in concurrent contexts is an optimisation in
itself,
> which
> limits these components to very specific architectures. For example,
Not really. I wasn't talking about methods and sync events, that was an
other post. What I'm talking about is this: If you are pushing data from
one component to an other over a data port you will have to choose an
appropriate algorithm to do so in a (thread) safe way. If your
components run in the same thread this is basically a memcpy().
Otherwise it may be a lock free alternative. It goes without saying that
the first is more efficient. To the components it does not matter what
algorithm is chosen. So they are not tied to very specific architectures
as you put it.
I wasn't talking about methods and sync events, that was an other post.
> starting
> and stopping components must also be controlled carefully.
> We don't encourage users to assume this use case for their components,
> unless they know what
> they're doing, so being a special case :-)
>
> Either way, rtt/extras is just a subdirectory of the official RTT, not
> a separate
> package that is doomed to degrade.
>
Sander.
First RTT 2.0 work package starts today.
On Jun 2, 2009, at 09:31 , Vandenbroucke Sander wrote:
>> -----Original Message-----
>> From: orocos-dev-bounces [..] ... [mailto:orocos-dev-
>> bounces [..] ...] On Behalf Of Peter Soetens
>> Sent: maandag 1 juni 2009 23:46
>> To: Orocos Developers
>> Subject: [Orocos-Dev] First RTT 2.0 work package starts today.
>>
>> The next three weeks, I'll be working on the steps necessary to make
>> the Real-Time Toolkit ready for improved portability and a better
>> structuring
>> of the build system and the directory structure. You can read all the
>> details
>> on the wiki here :
>> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup
>> The git repository is a branch in my current github orocos-rtt
> repository
>> here:
>> http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
>> (see for git instructions: http://www.orocos.org/wiki/rtt/git )
>>
>> Feel free to comment or ask questions about these items.
>>
>> I'll try to structure the work as such that most can be back-ported
>> to
> the
>> RTT
>> 1.x branch (on SVN). It's my hope that other operating systems than
>> GNU/Linux will already benefit from the work done, and that some of
> our
>> current Windows/Mac users in pain get a bit relief before I fully
> focus on
>> RTT 2.0-only topics.
>>
> I agree on most topics but I'm missing a few accents I mentioned
> before.
>
> 1.1:
> Ok.
>
> 1.2:
> Very welcome since CMake 2.6 has better cross-compiling support.
>
> 1.3:
> Ok
>
> 1.4:
> Sugestion: 1.4.3: An empty fosi implementation to start future ports
> from. Both for OS and CPU.
Maybe put this in the system examples instead of the runtime code base?
> 1.5:
> ... The user can switch between these modes at configuration or
> run-time.
> In my opinion this should be: The user can switch between these
> modes at
> configuration, run-time _OR_ compile time. Further more it should not
> add (much) code to the existing implementation. And I prefer to leave
> the 'much ' out of that last sentence.
>
> 1.6:
> Ok. We use CXX test, doesn't need any runtime library. Very useful on
> embedded targets.
Actually it does, just that they hid it. :-) CXXtest simply compiles
its library in with your code for each and every test program, one
reason that building cxxtest programs takes longer.
Stephen
First RTT 2.0 work package starts today.
On Tue, Jun 2, 2009 at 10:50 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Jun 2, 2009, at 16:31 , Klaas Gadeyne wrote:
>
>> On Tue, Jun 2, 2009 at 8:12 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
>>>
>>> On Jun 2, 2009, at 14:05 , Klaas Gadeyne wrote:
>>>
>>>> On Tue, Jun 2, 2009 at 2:17 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>> [...]
>>>>>
>>>>> 1.2.3 Please oh please oh please ... So the new method will be the
>>>>> CMake recommended approach ie use of CMAKE_PREFIX_PATH,
>>>>> CMAKE_INCLUDE_PATH, etc.?
>>>>
>>>> yes please :-)
>>>> I just ran into yet-another-symptom of this on mac os x
>>>>
>>>> ...
>>>> Linking CXX shared library liborocos-taskbrowser-macosx.dylib
>>>> ld: Undefined symbols:
>>>> _rl_completion_matches
>>>> _rl_free_line_state
>>>> _rl_set_signals
>>>>
>>>> Although setting cmake_include dir and cmake_library_dir
>>>>
>>>> $ nm /usr/lib/libreadline.dylib | grep _rl_completion_matches
>>>>
>>>> $ nm /sw/lib/libreadline.a | grep _rl_completion_matches
>>>> 00002b20 T _rl_completion_matches
>>>> U _rl_completion_matches
>>>>
>>>> Still ocl cmake selects the first one unless I explicitly change this
>>>> in the gui.
>>
>>> We just set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to point into
>>> Macports
>>> (/opt/local), and then run cmake and it figures it out for itself. No
>>> manual
>>> change necessary.
>>
>> I did this too [*](just as for RTT, where this works), but I doesn't
>> seem to work for OCL. Do you have readline installed in /usr/lib too?
>
> Yes.
>
> $ nm /usr/lib/libreadline.dylib | grep _rl_completion_matches
> $ nm /opt/local/lib/libreadline.dylib | grep _rl_completion_matches
> 00009270 T _rl_completion_matches
>
> I know this works for us, as I've hit it several times (when I get to a new
> machine, and have forgotten to set CMAKE_INCLUDE_PATH, etc). I set all of
> CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, and CMAKE_PROGRAM_PATH.
>
> I also have DYLD_LIBRARY_PATH set into the dir that Orocos is installed. Do
> not *imagine* that that has any affect on this (no readline in there after
> all).
>
> You do have an up to date OCL, right?
>
> $ svn di -c 29595 taskbrowser/CMakeLists.txt
> Index: taskbrowser/CMakeLists.txt
> ===================================================================
> --- taskbrowser/CMakeLists.txt (revision 29594)
> +++ taskbrowser/CMakeLists.txt (revision 29595)
> @@ -16,7 +16,7 @@
> GLOBAL_ADD_COMPONENT( orocos-taskbrowser ${SRCS} )
> GLOBAL_ADD_INCLUDE( ocl ${HPPS})
>
> - COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses readline )
> + COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses ${READLINE_LIBRARY} )
> COMPONENT_ADD_DEPS( orocos-taskbrowser orocos-ocl-common )
>
> ADD_SUBDIRECTORY( tests )
Yep (IIRC I even committed the above patch myself). I'll dig further
into this tomorrow.
k
First RTT 2.0 work package starts today.
> > 1.4:
> > Sugestion: 1.4.3: An empty fosi implementation to start future ports
> > from. Both for OS and CPU.
>
> Maybe put this in the system examples instead of the runtime code
base?
>
Ok.
> >
> > 1.6:
> > Ok. We use CXX test, doesn't need any runtime library. Very useful
on
> > embedded targets.
>
> Actually it does, just that they hid it. :-) CXXtest simply compiles
> its library in with your code for each and every test program, one
> reason that building cxxtest programs takes longer.
>
Of course. What I meant is that I don't have to worry about cross
compiling some obscure C++ lib with a thousand if-defs in it :-). I just
mentioned it as a simple to use alternative if you like unit testing on
target.
Sander.
First RTT 2.0 work package starts today.
On Mon, Jun 01, 2009 at 11:46:22PM +0200, Peter Soetens wrote:
> The next three weeks, I'll be working on the steps necessary to make
> the Real-Time Toolkit ready for improved portability and a better structuring
> of the build system and the directory structure. You can read all the details
> on the wiki here :
> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup
> The git repository is a branch in my current github orocos-rtt repository here:
> http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
> (see for git instructions: http://www.orocos.org/wiki/rtt/git )
>
> Feel free to comment or ask questions about these items.
>
> I'll try to structure the work as such that most can be back-ported to the RTT
> 1.x branch (on SVN). It's my hope that other operating systems than
> GNU/Linux will already benefit from the work done, and that some of our
> current Windows/Mac users in pain get a bit relief before I fully focus on
> RTT 2.0-only topics.
Great! Let us know when you want us to test...
Regards
Markus
First RTT 2.0 work package starts today.
On Jun 1, 2009, at 17:46 , Peter Soetens wrote:
> The next three weeks, I'll be working on the steps necessary to make
> the Real-Time Toolkit ready for improved portability and a better
> structuring
> of the build system and the directory structure. You can read all
> the details
> on the wiki here :
> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup
> The git repository is a branch in my current github orocos-rtt
> repository here:
> http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
> (see for git instructions: http://www.orocos.org/wiki/rtt/git )
1.2.1 This will cause problems for those running Ubuntu Hardy, which
is supported through 04/2011, and defaults to CMake 2.4.x. Backports
has CMake 2.6.x, but we should make sure we make this clear that the
default won't cut it.
1.2.2 I believe that SEPARATE_ARGUMENTS() can be used instead of the
LIST2STRING macro that I added to rtt/src/corba/CMakeLists.txt.
Appears to do the same thing. For those instances where strings crop
up ...
1.2.3 Please oh please oh please ... So the new method will be the
CMake recommended approach ie use of CMAKE_PREFIX_PATH,
CMAKE_INCLUDE_PATH, etc.?
1.2.4 Wonderful!!
1.2.5 SUGGESTED: Allow for a single file in perhaps the
CMAKE_SOURCE_DIR to specify local options (e.g. CORBA_IMPLEMENTATION,
ENABLE_CORBA, etc). A few months back someone mentioned a method of
doing this, but I don't remember enough to dig it up. This would be
really useful in all Orocos projects.
1.7 Seriously need this. Just check out the difference in the RTT
pkgconfig file on Mac OS X for corba=ACE vs corba=OmniORB. :-(
> I'll try to structure the work as such that most can be back-ported
> to the RTT
> 1.x branch (on SVN). It's my hope that other operating systems than
> GNU/Linux will already benefit from the work done, and that some of
> our
> current Windows/Mac users in pain get a bit relief before I fully
> focus on
> RTT 2.0-only topics.
So will this be available in SVN trunk for 2.x, or only with GIT? Will
we see any of this in the 1.x trunk prior to 2.0?
Thanks!
Stephen
First RTT 2.0 work package starts today.
On Tue, Jun 2, 2009 at 2:17 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
[...]
> 1.2.3 Please oh please oh please ... So the new method will be the
> CMake recommended approach ie use of CMAKE_PREFIX_PATH,
> CMAKE_INCLUDE_PATH, etc.?
yes please :-)
I just ran into yet-another-symptom of this on mac os x
...
Linking CXX shared library liborocos-taskbrowser-macosx.dylib
ld: Undefined symbols:
_rl_completion_matches
_rl_free_line_state
_rl_set_signals
Although setting cmake_include dir and cmake_library_dir
$ nm /usr/lib/libreadline.dylib | grep _rl_completion_matches
$ nm /sw/lib/libreadline.a | grep _rl_completion_matches
00002b20 T _rl_completion_matches
U _rl_completion_matches
Still ocl cmake selects the first one unless I explicitly change this
in the gui.
thx,
Klaas
First RTT 2.0 work package starts today.
On Jun 2, 2009, at 14:05 , Klaas Gadeyne wrote:
> On Tue, Jun 2, 2009 at 2:17 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
> [...]
>> 1.2.3 Please oh please oh please ... So the new method will be the
>> CMake recommended approach ie use of CMAKE_PREFIX_PATH,
>> CMAKE_INCLUDE_PATH, etc.?
>
> yes please :-)
> I just ran into yet-another-symptom of this on mac os x
>
> ...
> Linking CXX shared library liborocos-taskbrowser-macosx.dylib
> ld: Undefined symbols:
> _rl_completion_matches
> _rl_free_line_state
> _rl_set_signals
>
> Although setting cmake_include dir and cmake_library_dir
>
> $ nm /usr/lib/libreadline.dylib | grep _rl_completion_matches
>
> $ nm /sw/lib/libreadline.a | grep _rl_completion_matches
> 00002b20 T _rl_completion_matches
> U _rl_completion_matches
>
> Still ocl cmake selects the first one unless I explicitly change this
> in the gui.
>
> thx,
>
> Klaas
We just set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to point into
Macports (/opt/local), and then run cmake and it figures it out for
itself. No manual change necessary.
S
First RTT 2.0 work package starts today.
On Tue, Jun 2, 2009 at 8:12 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> On Jun 2, 2009, at 14:05 , Klaas Gadeyne wrote:
>
>> On Tue, Jun 2, 2009 at 2:17 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> [...]
>>>
>>> 1.2.3 Please oh please oh please ... So the new method will be the
>>> CMake recommended approach ie use of CMAKE_PREFIX_PATH,
>>> CMAKE_INCLUDE_PATH, etc.?
>>
>> yes please :-)
>> I just ran into yet-another-symptom of this on mac os x
>>
>> ...
>> Linking CXX shared library liborocos-taskbrowser-macosx.dylib
>> ld: Undefined symbols:
>> _rl_completion_matches
>> _rl_free_line_state
>> _rl_set_signals
>>
>> Although setting cmake_include dir and cmake_library_dir
>>
>> $ nm /usr/lib/libreadline.dylib | grep _rl_completion_matches
>>
>> $ nm /sw/lib/libreadline.a | grep _rl_completion_matches
>> 00002b20 T _rl_completion_matches
>> U _rl_completion_matches
>>
>> Still ocl cmake selects the first one unless I explicitly change this
>> in the gui.
> We just set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to point into Macports
> (/opt/local), and then run cmake and it figures it out for itself. No manual
> change necessary.
I did this too [*](just as for RTT, where this works), but I doesn't
seem to work for OCL. Do you have readline installed in /usr/lib too?
k
[*] Ofcourse I point to /sw/include and /sw/lib, as I use fink.
First RTT 2.0 work package starts today.
On Jun 2, 2009, at 16:31 , Klaas Gadeyne wrote:
> On Tue, Jun 2, 2009 at 8:12 PM, Stephen Roderick <kiwi [dot] net [..] ...>
> wrote:
>> On Jun 2, 2009, at 14:05 , Klaas Gadeyne wrote:
>>
>>> On Tue, Jun 2, 2009 at 2:17 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>> [...]
>>>>
>>>> 1.2.3 Please oh please oh please ... So the new method will be the
>>>> CMake recommended approach ie use of CMAKE_PREFIX_PATH,
>>>> CMAKE_INCLUDE_PATH, etc.?
>>>
>>> yes please :-)
>>> I just ran into yet-another-symptom of this on mac os x
>>>
>>> ...
>>> Linking CXX shared library liborocos-taskbrowser-macosx.dylib
>>> ld: Undefined symbols:
>>> _rl_completion_matches
>>> _rl_free_line_state
>>> _rl_set_signals
>>>
>>> Although setting cmake_include dir and cmake_library_dir
>>>
>>> $ nm /usr/lib/libreadline.dylib | grep _rl_completion_matches
>>>
>>> $ nm /sw/lib/libreadline.a | grep _rl_completion_matches
>>> 00002b20 T _rl_completion_matches
>>> U _rl_completion_matches
>>>
>>> Still ocl cmake selects the first one unless I explicitly change
>>> this
>>> in the gui.
>
>> We just set CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to point into
>> Macports
>> (/opt/local), and then run cmake and it figures it out for itself.
>> No manual
>> change necessary.
>
> I did this too [*](just as for RTT, where this works), but I doesn't
> seem to work for OCL. Do you have readline installed in /usr/lib too?
Yes.
$ nm /usr/lib/libreadline.dylib | grep _rl_completion_matches
$ nm /opt/local/lib/libreadline.dylib | grep _rl_completion_matches
00009270 T _rl_completion_matches
I know this works for us, as I've hit it several times (when I get to
a new machine, and have forgotten to set CMAKE_INCLUDE_PATH, etc). I
set all of CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, and
CMAKE_PROGRAM_PATH.
I also have DYLD_LIBRARY_PATH set into the dir that Orocos is
installed. Do not *imagine* that that has any affect on this (no
readline in there after all).
You do have an up to date OCL, right?
$ svn di -c 29595 taskbrowser/CMakeLists.txt
Index: taskbrowser/CMakeLists.txt
===================================================================
--- taskbrowser/CMakeLists.txt (revision 29594)
+++ taskbrowser/CMakeLists.txt (revision 29595)
@@ -16,7 +16,7 @@
GLOBAL_ADD_COMPONENT( orocos-taskbrowser ${SRCS} )
GLOBAL_ADD_INCLUDE( ocl ${HPPS})
- COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses readline )
+ COMPONENT_ADD_LIBS( orocos-taskbrowser ncurses $
{READLINE_LIBRARY} )
COMPONENT_ADD_DEPS( orocos-taskbrowser orocos-ocl-common )
ADD_SUBDIRECTORY( tests )
First RTT 2.0 work package starts today.
On Tue, Jun 2, 2009 at 02:17, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Jun 1, 2009, at 17:46 , Peter Soetens wrote:
>
>> The next three weeks, I'll be working on the steps necessary to make
>> the Real-Time Toolkit ready for improved portability and a better
>> structuring
>> of the build system and the directory structure. You can read all the
>> details
>> on the wiki here :
>> http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup
>> The git repository is a branch in my current github orocos-rtt repository
>> here:
>> http://github.com/psoetens/orocos-rtt/tree/rtt-2.0-mainline
>> (see for git instructions: http://www.orocos.org/wiki/rtt/git )
>
> 1.2.1 This will cause problems for those running Ubuntu Hardy, which is
> supported through 04/2011, and defaults to CMake 2.4.x. Backports has CMake
> 2.6.x, but we should make sure we make this clear that the default won't cut
> it.
Since it's a developer/build-side issue, I think we can live with this. A CMake
version detection and proper error message is still required.
>
> 1.2.2 I believe that SEPARATE_ARGUMENTS() can be used instead of the
> LIST2STRING macro that I added to rtt/src/corba/CMakeLists.txt. Appears to
> do the same thing. For those instances where strings crop up ...
Now that you mentioned it, I wondered before what this CMake macro was
useful for...
>
> 1.2.3 Please oh please oh please ... So the new method will be the CMake
> recommended approach ie use of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, etc.?
Yes, 100%
>
> 1.2.4 Wonderful!!
>
> 1.2.5 SUGGESTED: Allow for a single file in perhaps the CMAKE_SOURCE_DIR to
> specify local options (e.g. CORBA_IMPLEMENTATION, ENABLE_CORBA, etc). A few
> months back someone mentioned a method of doing this, but I don't remember
> enough to dig it up. This would be really useful in all Orocos projects.
This was on the boost unit tests branch, and is now also on the
rtt-2.0-mainline. It will
also be backported to 1.x
>
> 1.7 Seriously need this. Just check out the difference in the RTT pkgconfig
> file on Mac OS X for corba=ACE vs corba=OmniORB. :-(
I'm also concerned with systems that don't have a .pc file or system
(like Windows)
I wonder how such problems are solved on that platform...
>
>> I'll try to structure the work as such that most can be back-ported to the
>> RTT
>> 1.x branch (on SVN). It's my hope that other operating systems than
>> GNU/Linux will already benefit from the work done, and that some of our
>> current Windows/Mac users in pain get a bit relief before I fully focus on
>> RTT 2.0-only topics.
>
> So will this be available in SVN trunk for 2.x, or only with GIT? Will we
> see any of this in the 1.x trunk prior to 2.0?
RTT 2.0 is GIT only. RTT 1.x remains on SVN. Backporting happens as soon
as possible, preferably during the WP, such that it's fresh in memory and that
1.x users can test it.
Peter