So I appear to be back from holidays...
I'm preparing 1.10.4 and 1.12.0. The former is mainly what's on the rtt|
ocl-1.10 branches, the latter what's on the rtt|ocl/trunk.
These releases mainly fix issues with scripting and corba, and with
checking/using dependencies such as boost or Xenomai. I'd also like to have a
working TimerComponent again in 1.12 :-]
I've seen some pull requests from Stephen, but it's a bit unclear what needs
to be merged where. Just merge 'next' onto rtt-1.0-svn-patches ?
Now is also a good moment to yell in a (open) bug report for urgent fix
requests.
On the 2.0 front, I'm finishing up the plugin loading in RTT as discussed some
time ago on this list. It uses boost::filesystem, and the dlopen API such that
we can use the dlopen wrapper on Win32 to support plugins there too. After
this change, typekits and APIs should be stable enough to start creating
release candidates. ROS integration/interoperation is still on the agenda too,
especially wrt generating typekits from ros message types.
Peter
Pulling git branches for next releases
On Jun 17, 2010, at 11:25 , Peter Soetens wrote:
> So I appear to be back from holidays...
Fantastic. Hope you had a great relaxing trip!
> I'm preparing 1.10.4 and 1.12.0. The former is mainly what's on the rtt|
> ocl-1.10 branches, the latter what's on the rtt|ocl/trunk.
>
> These releases mainly fix issues with scripting and corba, and with
> checking/using dependencies such as boost or Xenomai. I'd also like to have a
> working TimerComponent again in 1.12 :-]
It's not working? News to me ... and we use it a lot. Of course, some of my patches below may fix things ...?
> I've seen some pull requests from Stephen, but it's a bit unclear what needs
> to be merged where. Just merge 'next' onto rtt-1.0-svn-patches ?
All the following are onto the v1 trunk of RTT and OCL.
RTT
next - fixes for trunk
next-virtual-clocks - adds multiple time services (aka clocks). you could take this. I think it is pretty clean.
next-rtlogging - real time logging additions, I'd skip this for now
OCL
next - fixes for trunk
next-boost-plugin - a boost date/time plugin. you could take this.
next-rtalloc - real-time allocation, your call on this one
next-logging - add log4cpp-based logging to OCL. Requires OCL::next-rtalloc. Does _not_ require RTT::next-rtlogging (IIRC)
next-virtual-clocks - add support to OCL::TimerComponent for RTT::next-virtual-clocks, and for loading of TimeServices in general during deployment.
The OCL boost plugin we've been using for months.
The OCL rtalloc+logging we've been using for months. It is stable on Ubuntu and Snow Leopard. IIRC they default off.
I've done a fair bit of testing and use on the virtual-clocks topics, but they could possibly use some additional time.
The RTT rtlogging still has some issues. Mostly due to tying together the log levels of RTT and log4cpp.
> Now is also a good moment to yell in a (open) bug report for urgent fix
> requests.
>
> On the 2.0 front, I'm finishing up the plugin loading in RTT as discussed some
> time ago on this list. It uses boost::filesystem, and the dlopen API such that
> we can use the dlopen wrapper on Win32 to support plugins there too. After
> this change, typekits and APIs should be stable enough to start creating
> release candidates. ROS integration/interoperation is still on the agenda too,
> especially wrt generating typekits from ros message types.
So when are we likely to see the first official release?
S
Pulling git branches for next releases
On Thu, Jun 17, 2010 at 17:25, Peter Soetens <peter [..] ...>wrote:
> So I appear to be back from holidays...
>
We had already noticed after 5 minutes :)
>
> I'm preparing 1.10.4 and 1.12.0. The former is mainly what's on the rtt|
> ocl-1.10 branches, the latter what's on the rtt|ocl/trunk.
>
> These releases mainly fix issues with scripting and corba, and with
> checking/using dependencies such as boost or Xenomai. I'd also like to have
> a
> working TimerComponent again in 1.12 :-]
>
> I've seen some pull requests from Stephen, but it's a bit unclear what
> needs
> to be merged where. Just merge 'next' onto rtt-1.0-svn-patches ?
>
> Now is also a good moment to yell in a (open) bug report for urgent fix
> requests.
>
> On the 2.0 front, I'm finishing up the plugin loading in RTT as discussed
> some
> time ago on this list. It uses boost::filesystem, and the dlopen API such
> that
> we can use the dlopen wrapper on Win32 to support plugins there too. After
> this change, typekits and APIs should be stable enough to start creating
> release candidates. ROS integration/interoperation is still on the agenda
> too,
> especially wrt generating typekits from ros message types.
>
Concerning the ROS integration there is some recent progress on publishing
orocos dataports as ROS topics (see also the mail of Enea).
I think it's the right time to start a thorough discussion on how to
progress with the integration (especially for the services, methods, ...)
Are we going to directly develop on 2.0 or continue from 1.10 as we are
doing now?
(For the methods versus services this might be an important decision?)
Tinne
>
> Peter
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
Pulling git branches for next releases
On Thursday 17 June 2010 17:31:22 Tinne De Laet wrote:
> On Thu, Jun 17, 2010 at 17:25, Peter Soetens
<peter [..] ...>wrote:
> > So I appear to be back from holidays...
>
> We had already noticed after 5 minutes :)
>
> > I'm preparing 1.10.4 and 1.12.0. The former is mainly what's on the rtt|
> > ocl-1.10 branches, the latter what's on the rtt|ocl/trunk.
> >
> > These releases mainly fix issues with scripting and corba, and with
> > checking/using dependencies such as boost or Xenomai. I'd also like to
> > have a
> > working TimerComponent again in 1.12 :-]
> >
> > I've seen some pull requests from Stephen, but it's a bit unclear what
> > needs
> > to be merged where. Just merge 'next' onto rtt-1.0-svn-patches ?
> >
> > Now is also a good moment to yell in a (open) bug report for urgent fix
> > requests.
> >
> > On the 2.0 front, I'm finishing up the plugin loading in RTT as discussed
> > some
> > time ago on this list. It uses boost::filesystem, and the dlopen API such
> > that
> > we can use the dlopen wrapper on Win32 to support plugins there too.
> > After this change, typekits and APIs should be stable enough to start
> > creating release candidates. ROS integration/interoperation is still on
> > the agenda too,
> > especially wrt generating typekits from ros message types.
>
> Concerning the ROS integration there is some recent progress on publishing
> orocos dataports as ROS topics (see also the mail of Enea).
I think this provides valuable input from a use case perspective and possible
solutions.
> I think it's the right time to start a thorough discussion on how to
> progress with the integration (especially for the services, methods, ...)
I propose to create a wiki page that contains all ideas/descisions.
> Are we going to directly develop on 2.0 or continue from 1.10 as we are
> doing now?
> (For the methods versus services this might be an important decision?)
It makes no sense to put tremendous energy in the 1.x line for ROS support.
2.x is far more compatible (in concepts and in code) with ROS than 1.x. 1.x
can only support ROS topics (a little). I am not maintaining the 1.x ROS
support line. I'm assuming the original authors are taking responsibility
there, or declare it officially as deprecated (ie scheduled for removal).
Peter