It has been taking a bit longer than expected, but the new
Activity/Thread classes pass unit tests on GNU/Linux/RTAI/Xenomai[*].
I feel quite confident now to push these changes to the stable branch
and start making the Activity the default activity for TaskContexts,
although that last feature is still in the making. The idea remains
that all work up until now can be merged on the 1.x branch.
Open items are now:
(http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup)
WP 1.1 Partition in name spaces and hide internal classes in subdirectories.
and WP 1.3 Group user contributed code in rtt/extras.
==> up next, won't be mergable on 1.x branch
WP 1.5 Default to activity with one thread per component
==> merge in default to 'Activity'. Making timeouts for stop()
configurable is still an open issue, because this would essentially
propagate to the TaskContext::stop() function as well.
WP 1.7 Provide CMake macros for applications and components
==> need your help here. Didn't someone propose a new
FindOrocosRTT/OCL.cmake macro (Adolfo?).
WP 1.8 Allow lock-free policies to be configured
==> might be postponed to WP 3, when the execution layer is reworked.
The other work packages are finished as far as I am concerned. I
wanted to finish all this by Friday btw :-)
I need another day for fixing up the XML manuals as well.
As usual, these changes are only available on the github repository.
Peter
[*] There's also an open issue with Boost.Test. Our test-runner.cpp
does not call the __os_exit() function at the right time, causing an
exception upon test program termination when using Xenomai. I disabled
__os_exit() for unit tests on Xenomai for now. The function itself is
tested in a new test 'test-main' which doesn't use Boost.Test.
RTT 2.0 Status update
On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens<peter [dot] soetens [..] ...> wrote:
[...]
> Open items are now:
> (http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup)
Maybe a little OT given the current state of affairs, but I noticed
that the UML2 like statemachines are not mentioned (yet/any more) on
this roadmap for 2.0?
Klaas
RTT 2.0 Status update
On Wed, Jun 17, 2009 at 09:39:02AM +0200, Klaas Gadeyne wrote:
> On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens<peter [dot] soetens [..] ...> wrote:
> [...]
> > Open items are now:
> > (http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup)
>
> Maybe a little OT given the current state of affairs, but I noticed
> that the UML2 like statemachines are not mentioned (yet/any more) on
> this roadmap for 2.0?
I guess thats because it's not Peter who will be doing that part,
however UML2 FSM are certainly planned within the 2.0 timeframe.
Markus
RTT 2.0 Status update
On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens <peter [dot] soetens [..] ...>wrote:
> It has been taking a bit longer than expected, but the new
> Activity/Thread classes pass unit tests on GNU/Linux/RTAI/Xenomai[*].
> I feel quite confident now to push these changes to the stable branch
> and start making the Activity the default activity for TaskContexts,
> although that last feature is still in the making. The idea remains
> that all work up until now can be merged on the 1.x branch.
>
> Open items are now:
> (http://www.orocos.org/wiki/rtt/rtt-20/detailed-roadmap/rtt-cleanup)
>
> WP 1.1 Partition in name spaces and hide internal classes in
> subdirectories.
> and WP 1.3 Group user contributed code in rtt/extras.
> ==> up next, won't be mergable on 1.x branch
>
> WP 1.5 Default to activity with one thread per component
> ==> merge in default to 'Activity'. Making timeouts for stop()
> configurable is still an open issue, because this would essentially
> propagate to the TaskContext::stop() function as well.
>
> WP 1.7 Provide CMake macros for applications and components
> ==> need your help here. Didn't someone propose a new
> FindOrocosRTT/OCL.cmake macro (Adolfo?).
Before I send something, I have two questions:
- Are we maintaining pkgconfig-based scripts?
- Are we dropping the <package>_ROOT_DIR variables in favor of
CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH?
I'm currently assuming that the answer to both questions is yes from what
was voiced in previous threads. I just want to ensure that I'm on the same
page.
Adolfo.
>
> WP 1.8 Allow lock-free policies to be configured
> ==> might be postponed to WP 3, when the execution layer is reworked.
>
> The other work packages are finished as far as I am concerned. I
> wanted to finish all this by Friday btw :-)
>
> I need another day for fixing up the XML manuals as well.
>
> As usual, these changes are only available on the github repository.
>
> Peter
>
> [*] There's also an open issue with Boost.Test. Our test-runner.cpp
> does not call the __os_exit() function at the right time, causing an
> exception upon test program termination when using Xenomai. I disabled
> __os_exit() for unit tests on Xenomai for now. The function itself is
> tested in a new test 'test-main' which doesn't use Boost.Test.
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
RTT 2.0 Status update
2009/6/16 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens <peter [dot] soetens [..] ...>
> wrote:
>>
>> WP 1.7 Provide CMake macros for applications and components
>> ==> need your help here. Didn't someone propose a new
>> FindOrocosRTT/OCL.cmake macro (Adolfo?).
>
> Before I send something, I have two questions:
> - Are we maintaining pkgconfig-based scripts?
Yes.
> - Are we dropping the <package>_ROOT_DIR variables in favor of
> CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH?
Yes.
>
> I'm currently assuming that the answer to both questions is yes from what
> was voiced in previous threads. I just want to ensure that I'm on the same
> page.
You are !
Peter
RTT 2.0 Status update
2009/6/17 Peter Soetens <peter [dot] soetens [..] ...>
> 2009/6/16 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>:
> >
> >
> > On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens <peter [dot] soetens [..] ...>
> > wrote:
> >>
> >> WP 1.7 Provide CMake macros for applications and components
> >> ==> need your help here. Didn't someone propose a new
> >> FindOrocosRTT/OCL.cmake macro (Adolfo?).
> >
> > Before I send something, I have two questions:
> > - Are we maintaining pkgconfig-based scripts?
>
> Yes.
>
> > - Are we dropping the <package>_ROOT_DIR variables in favor of
> > CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH?
>
> Yes.
Sorry if I repeat myself, but I still have issues with the granularity of
this approach, so I have one question to ask. What would happen if I have 2
versions of a package in my system:
- One in a standard location like /usr
- One in a nostandard location
Now say that I want to build RTT using the package located in the
nonstandard location. How would I ensure that cmake picks it up, and _not_
the one in /usr? I haven't played with CMAKE_INCLUDE_PATH and
CMAKE_LIBRARY_PATH much, but from reading here [1] I get the impression that
this is not going to happen.
My point is, these variables seem OK for finding a package that is installed
once in your system, maybe in a nonstandard location, maybe not, but they
do not seem to allow you to select between more than one alternative (e.g.,
when testing a new version of an external dep.).
So what's the standpoint on this? adopt CMAKE_INCLUDE_PATH and
CMAKE_LIBRARY_PATH and let these more obscure and less common use cases be
solved by manual cache-editing?
[1] http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_path
>
>
> >
> > I'm currently assuming that the answer to both questions is yes from what
> > was voiced in previous threads. I just want to ensure that I'm on the
> same
> > page.
>
> You are !
>
> Peter
>
RTT 2.0 Status update
2009/6/17 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...>:
>
>
> 2009/6/17 Peter Soetens <peter [dot] soetens [..] ...>
>>
>> 2009/6/16 Adolfo Rodríguez Tsouroukdissian
>> <adolfo [dot] rodriguez [..] ...>:
>> >
>> >
>> > On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens <peter [dot] soetens [..] ...>
>> > wrote:
>> >>
>> >> WP 1.7 Provide CMake macros for applications and components
>> >> ==> need your help here. Didn't someone propose a new
>> >> FindOrocosRTT/OCL.cmake macro (Adolfo?).
>> >
>> > Before I send something, I have two questions:
>> > - Are we maintaining pkgconfig-based scripts?
>>
>> Yes.
>>
>> > - Are we dropping the <package>_ROOT_DIR variables in favor of
>> > CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH?
>>
>> Yes.
>
>
> Sorry if I repeat myself, but I still have issues with the granularity of
> this approach, so I have one question to ask. What would happen if I have 2
> versions of a package in my system:
> - One in a standard location like /usr
> - One in a nostandard location
>
> Now say that I want to build RTT using the package located in the
> nonstandard location. How would I ensure that cmake picks it up, and _not_
> the one in /usr? I haven't played with CMAKE_INCLUDE_PATH and
> CMAKE_LIBRARY_PATH much, but from reading here [1] I get the impression that
> this is not going to happen.
CMAKE_X_PATH takes precedence over default system paths. Isn't this
what you require ??
I successfully used this with boost. I got 1.37 installed in /usr and
1.39 installed in my
home directory. By setting the cmake path variables, 1.39 was picked up.
Peter
RTT 2.0 Status update
2009/6/17 Peter Soetens <peter [dot] soetens [..] ...>
> 2009/6/17 Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...>:
> >
> >
> > 2009/6/17 Peter Soetens <peter [dot] soetens [..] ...>
> >>
> >> 2009/6/16 Adolfo Rodríguez Tsouroukdissian
> >> <adolfo [dot] rodriguez [..] ...>:
> >> >
> >> >
> >> > On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens <
> peter [dot] soetens [..] ...>
> >> > wrote:
> >> >>
> >> >> WP 1.7 Provide CMake macros for applications and components
> >> >> ==> need your help here. Didn't someone propose a new
> >> >> FindOrocosRTT/OCL.cmake macro (Adolfo?).
> >> >
> >> > Before I send something, I have two questions:
> >> > - Are we maintaining pkgconfig-based scripts?
> >>
> >> Yes.
> >>
> >> > - Are we dropping the <package>_ROOT_DIR variables in favor of
> >> > CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH?
> >>
> >> Yes.
> >
> >
> > Sorry if I repeat myself, but I still have issues with the granularity of
> > this approach, so I have one question to ask. What would happen if I have
> 2
> > versions of a package in my system:
> > - One in a standard location like /usr
> > - One in a nostandard location
> >
> > Now say that I want to build RTT using the package located in the
> > nonstandard location. How would I ensure that cmake picks it up, and
> _not_
> > the one in /usr? I haven't played with CMAKE_INCLUDE_PATH and
> > CMAKE_LIBRARY_PATH much, but from reading here [1] I get the impression
> that
> > this is not going to happen.
>
> CMAKE_X_PATH takes precedence over default system paths. Isn't this
> what you require ??
>
> I successfully used this with boost. I got 1.37 installed in /usr and
> 1.39 installed in my
> home directory. By setting the cmake path variables, 1.39 was picked up.
>
OK. That's all I need to know :-)
I thought the system paths would take precedence.
Adolfo.
>
> Peter
>
RTT 2.0 Status update
On Jun 17, 2009, at 08:13 , Adolfo Rodríguez Tsouroukdissian wrote:
>
> 2009/6/17 Peter Soetens <peter [dot] soetens [..] ...>
> 2009/6/17 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
> >:
> >
> >
> > 2009/6/17 Peter Soetens <peter [dot] soetens [..] ...>
> >>
> >> 2009/6/16 Adolfo Rodríguez Tsouroukdissian
> >> <adolfo [dot] rodriguez [..] ...>:
> >> >
> >> >
> >> > On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens <peter [dot] soetens [..] ...
> >
> >> > wrote:
> >> >>
> >> >> WP 1.7 Provide CMake macros for applications and components
> >> >> ==> need your help here. Didn't someone propose a new
> >> >> FindOrocosRTT/OCL.cmake macro (Adolfo?).
> >> >
> >> > Before I send something, I have two questions:
> >> > - Are we maintaining pkgconfig-based scripts?
> >>
> >> Yes.
> >>
> >> > - Are we dropping the <package>_ROOT_DIR variables in favor of
> >> > CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH?
> >>
> >> Yes.
> >
> >
> > Sorry if I repeat myself, but I still have issues with the
> granularity of
> > this approach, so I have one question to ask. What would happen if
> I have 2
> > versions of a package in my system:
> > - One in a standard location like /usr
> > - One in a nostandard location
> >
> > Now say that I want to build RTT using the package located in the
> > nonstandard location. How would I ensure that cmake picks it up,
> and _not_
> > the one in /usr? I haven't played with CMAKE_INCLUDE_PATH and
> > CMAKE_LIBRARY_PATH much, but from reading here [1] I get the
> impression that
> > this is not going to happen.
>
> CMAKE_X_PATH takes precedence over default system paths. Isn't this
> what you require ??
>
> I successfully used this with boost. I got 1.37 installed in /usr and
> 1.39 installed in my
> home directory. By setting the cmake path variables, 1.39 was picked
> up.
>
> OK. That's all I need to know :-)
> I thought the system paths would take precedence.
If this becomes a problem, it is easy to overcome. As noted in the
CMake doc's, you put two versions of the same statement: one with a
flag to not use system paths, and one without the flag (which will
therefore include the system paths).
Stephen
RTT 2.0 Status update
On Wed, 17 Jun 2009, Adolfo Rodríguez Tsouroukdissian wrote:
> 2009/6/17 Peter Soetens <peter [dot] soetens [..] ...>
>
>> 2009/6/16 Adolfo Rodríguez Tsouroukdissian <
>> adolfo [dot] rodriguez [..] ...>:
>>>
>>>
>>> On Tue, Jun 16, 2009 at 5:21 PM, Peter Soetens <peter [dot] soetens [..] ...>
>>> wrote:
>>>>
>>>> WP 1.7 Provide CMake macros for applications and components
>>>> ==> need your help here. Didn't someone propose a new
>>>> FindOrocosRTT/OCL.cmake macro (Adolfo?).
>>>
>>> Before I send something, I have two questions:
>>> - Are we maintaining pkgconfig-based scripts?
>>
>> Yes.
>>
>>> - Are we dropping the <package>_ROOT_DIR variables in favor of
>>> CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH?
>>
>> Yes.
>
>
> Sorry if I repeat myself, but I still have issues with the granularity of
> this approach, so I have one question to ask. What would happen if I have 2
> versions of a package in my system:
> - One in a standard location like /usr
> - One in a nostandard location
>
> Now say that I want to build RTT using the package located in the
> nonstandard location. How would I ensure that cmake picks it up, and _not_
> the one in /usr? I haven't played with CMAKE_INCLUDE_PATH and
> CMAKE_LIBRARY_PATH much, but from reading here [1] I get the impression that
> this is not going to happen.
> My point is, these variables seem OK for finding a package that is installed
> once in your system, maybe in a nonstandard location, maybe not, but they
> do not seem to allow you to select between more than one alternative (e.g.,
> when testing a new version of an external dep.).
I don't recall exactly, so I might be completely wrong here, but as far as I know I have used this approach to select stuff in /sw on my mac which is also installed, and it works fine. And as this seems to be a common scenario in case you are cross-compiling, I think it should work. What's the exact statement in [1] which makes you think it won't work?
Klaas
> So what's the standpoint on this? adopt CMAKE_INCLUDE_PATH and
> CMAKE_LIBRARY_PATH and let these more obscure and less common use cases be
> solved by manual cache-editing?
>
> [1] http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_path
>
>
>>
>>
>>>
>>> I'm currently assuming that the answer to both questions is yes from what
>>> was voiced in previous threads. I just want to ensure that I'm on the
>> same
>>> page.
>>
>> You are !
>>
>> Peter
>>
>
>
>
>