The Orocos Toolchain developers are content[1] to announce the 2.6 release cycle of the Orocos Toolchain. As in the previous release cycle, the emphasis is on stability, incremental development and stable API's. The major additions in this release are:
- stable typekits: we can now load typekits from all kinds of sources (hand written, ROS, yarp, typegen,...) without having conflicts in names or functionality
- RTT added a CIRCULAR_BUFFER connection policy: drops oldest sample instead of newest
- Revamped OCL reporter with NetCDF support: reporting is now about 100-1000 times faster / less cpu intensive than before - and is compatible and more efficient with KST2
- Updated orogen component generation framework
- C++ runaway exceptions in operations are now caught by RTT and bring your component to the Exception state.
- Many updates to deployment: allow to connect provides() and requires() operations, have shutdown and daemon support.
- Improved tlsf, logging and corba support for rttlua
Under the hood, these changes make a difference too:
- We achieved hard real-time operation calls for rttlua-tlsf: due to stable typekits, we can now do typeinfo caching eliminating the last source of memory allocations and improving performance.
- We log PID/TID numbers on Linux systems when Activity objects are created, such that you can relate to them using 'top'.
- We mutex-lock the TypeInfoRepository to allow multi-threaded imports of typekits (typically in iTaSC / rttlua apps)
- We moved the component loader to RTT such that you don't need OCL to load components in applications.
Some more details can be found on the 2.6 Release notes here: http://www.orocos.org/stable/documentation/rtt/v2.6.x/doc-xml/orocos-rtt-changes.html
You can download this release using the bootstrap script on the website, or pointing your autoproj configuration to the toolchain-2.6 branch, or by fetching the ROS Fuerte Ubuntu packages.
http://www.orocos.org/wiki/orocos/toolchain/quick-start
Since the majority of the Orocos users uses one of these three methods, it remains to be seen if a 'dot' release will be made. I would only do so to communicate to newcomers that we do make bugfixes on a regular basis.
Thanks to the many Orocos users and developers who have contributed to this truely major release.
Peter
[1] adjective : satisfied with what one is or has; not wanting more or anything else.
[Orocos] Orocos Toolchain 2.6.0 Released !
Hello Peter.
Some words about the last release :
(1) Thank you for having managed this new release.
(2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
(3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
(4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
(3) The bug 926 haven't been merged. Do you have suggestions to make the patch acceptable ?
(5) I think you can close bug 853
Regards.
Paul.
On 12/03/2012 11:53 PM, Peter Soetens wrote:
> The Orocos Toolchain developers are content[1] to announce the 2.6
> release cycle of the Orocos Toolchain. As in the previous release
> cycle, the emphasis is on stability, incremental development and
> stable API's. The major additions in this release are:
> - stable typekits: we can now load typekits from all kinds of sources
> (hand written, ROS, yaml, typegen,...) without having conflicts in
> names or functionality
> - RTT added a CIRCULAR_BUFFER connection policy: drops oldest sample
> instead of newest
> - Revamped OCL reporter with NetCDF support: reporting is now about
> 100-1000 times faster / less cpu intensive than before - and is
> compatible and more efficient with KST2
> - Updated orogen component generation framework
> - C++ runaway exceptions in operations are now caught by RTT and
> bring your component to the Exception state.
> - Many updates to deployment: allow to connect provides() and
> requires() operations, have shutdown and daemon support.
> - Improved tlsf, logging and corba support for rttlua
>
> Under the hood, these changes make a difference too:
> - We achieved hard real-time operation calls for rttlua-tlsf: due to
> stable typekits, we can now do typeinfo caching eliminating the last
> source of memory allocations and improving performance.
> - We log PID/TID numbers on Linux systems when Activity objects are
> created, such that you can relate to them using 'top'.
> - We mutex-lock the TypeInfoRepository to allow multi-threaded
> imports of typekits (typically in iTaSC / rttlua apps)
> - We moved the component loader to RTT such that you don't need OCL
> to load components in applications.
>
> Some more details can be found on the 2.6 Release notes here:
> http://www.orocos.org/stable/documentation/rtt/v2.6.x/doc-xml/orocos-rtt...
>
> You can download this release using the bootstrap script on the
> website, or pointing your autoproj configuration to the toolchain-2.6
> branch, or by fetching the ROS Fuerte Ubuntu packages.
>
> http://www.orocos.org/wiki/orocos/toolchain/quick-start
>
> Since the majority of the Orocos users uses one of these three
> methods, it remains to be seen if a 'dot' release will be made.
> I would only do so to communicate to newcomers that we do make
> bugfixes on a regular basis.
>
> Thanks to the many Orocos users and developers who have contributed to
> this truely major release.
>
> Peter
>
> [1] adjective : satisfied with what one is or has; not wanting more or
> anything else.
>
[Orocos] Orocos Toolchain 2.6.0 Released !
Hello Peter.
Some words about the last release :
(1) Thank you for having managed this new release.
(2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
(3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
(4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
(3) The bug 926 haven't been merged. Do you have suggestions to make the patch acceptable ?
(5) I think you can close bug 853
Regards.
Paul.
On 12/03/2012 11:53 PM, Peter Soetens wrote:
> The Orocos Toolchain developers are content[1] to announce the 2.6
> release cycle of the Orocos Toolchain. As in the previous release
> cycle, the emphasis is on stability, incremental development and
> stable API's. The major additions in this release are:
> - stable typekits: we can now load typekits from all kinds of sources
> (hand written, ROS, yaml, typegen,...) without having conflicts in
> names or functionality
> - RTT added a CIRCULAR_BUFFER connection policy: drops oldest sample
> instead of newest
> - Revamped OCL reporter with NetCDF support: reporting is now about
> 100-1000 times faster / less cpu intensive than before - and is
> compatible and more efficient with KST2
> - Updated orogen component generation framework
> - C++ runaway exceptions in operations are now caught by RTT and
> bring your component to the Exception state.
> - Many updates to deployment: allow to connect provides() and
> requires() operations, have shutdown and daemon support.
> - Improved tlsf, logging and corba support for rttlua
>
> Under the hood, these changes make a difference too:
> - We achieved hard real-time operation calls for rttlua-tlsf: due to
> stable typekits, we can now do typeinfo caching eliminating the last
> source of memory allocations and improving performance.
> - We log PID/TID numbers on Linux systems when Activity objects are
> created, such that you can relate to them using 'top'.
> - We mutex-lock the TypeInfoRepository to allow multi-threaded
> imports of typekits (typically in iTaSC / rttlua apps)
> - We moved the component loader to RTT such that you don't need OCL
> to load components in applications.
>
> Some more details can be found on the 2.6 Release notes here:
> http://www.orocos.org/stable/documentation/rtt/v2.6.x/doc-xml/orocos-rtt...
>
> You can download this release using the bootstrap script on the
> website, or pointing your autoproj configuration to the toolchain-2.6
> branch, or by fetching the ROS Fuerte Ubuntu packages.
>
> http://www.orocos.org/wiki/orocos/toolchain/quick-start
>
> Since the majority of the Orocos users uses one of these three
> methods, it remains to be seen if a 'dot' release will be made.
> I would only do so to communicate to newcomers that we do make
> bugfixes on a regular basis.
>
> Thanks to the many Orocos users and developers who have contributed to
> this truely major release.
>
> Peter
>
> [1] adjective : satisfied with what one is or has; not wanting more or
> anything else.
>
[Orocos] Orocos Toolchain 2.6.0 Released !
Hi Paul,
On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
> Hello Peter.
>
> Some words about the last release :
>
> (1) Thank you for having managed this new release.
>
> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
There is an issue with the file server which caused all our new
uploads to be not available on the webserver. We've reported it and
hope it will be resolved soon. You can get rtt and ocl as archives
from github or gitorious. The complete toolchain we could try to
upload to a different place and see if we can manually move it on the
webserver...
>
> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
I did, but then I forgot.. patch is king :-) Fixed on gitorious.
>
> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
What really sucks is that the rttlua deployer is called 'deployer' and
the taskbrowser deployer is called 'Deployer'. Changing either of
both is going to break a lot of scripts.
Especially since every rttlua script contains a line like 'dp =
tc:getPeer("deployer")'
What we could do is try to use the alias mechanism such that
'deployer' and 'Deployer' resolve to the same TC, *but keep the
official name as 'deployer' in rttlua*.
For example (note that the DC is created as "deployer"):
diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
index 0a56197..22d03b9 100644
[Orocos] Orocos Toolchain 2.6.0 Released !
Hi Paul,
On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
> Hello Peter.
>
> Some words about the last release :
>
> (1) Thank you for having managed this new release.
>
> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
There is an issue with the file server which caused all our new
uploads to be not available on the webserver. We've reported it and
hope it will be resolved soon. You can get rtt and ocl as archives
from github or gitorious. The complete toolchain we could try to
upload to a different place and see if we can manually move it on the
webserver...
>
> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
I did, but then I forgot.. patch is king :-) Fixed on gitorious.
>
> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
What really sucks is that the rttlua deployer is called 'deployer' and
the taskbrowser deployer is called 'Deployer'. Changing either of
both is going to break a lot of scripts.
Especially since every rttlua script contains a line like 'dp =
tc:getPeer("deployer")'
What we could do is try to use the alias mechanism such that
'deployer' and 'Deployer' resolve to the same TC, *but keep the
official name as 'deployer' in rttlua*.
For example (note that the DC is created as "deployer"):
diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
index 0a56197..22d03b9 100644
[Orocos] Orocos Toolchain 2.6.0 Released !
Hi
On 12/11/2012 12:15 PM, Peter Soetens wrote:
> Hi Paul,
>
> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>> Hello Peter.
>>
>> Some words about the last release :
>>
>> (1) Thank you for having managed this new release.
>>
>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
>
> There is an issue with the file server which caused all our new
> uploads to be not available on the webserver. We've reported it and
> hope it will be resolved soon. You can get rtt and ocl as archives
> from github or gitorious. The complete toolchain we could try to
> upload to a different place and see if we can manually move it on the
> webserver...
>
I hope your Fiber channel controller won't cause too many problem to fixup.
>>
>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
>
> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
Thank you.
>
>>
>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
>
> What really sucks is that the rttlua deployer is called 'deployer' and
> the taskbrowser deployer is called 'Deployer'. Changing either of
> both is going to break a lot of scripts.
>
> Especially since every rttlua script contains a line like 'dp =
> tc:getPeer("deployer")'
>
> What we could do is try to use the alias mechanism such that
> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
> official name as 'deployer' in rttlua*.
>
> For example (note that the DC is created as "deployer"):
>
> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
> index 0a56197..22d03b9 100644
[Orocos] Orocos Toolchain 2.6.0 Released !
On Tue, Dec 11, 2012 at 3:43 PM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
> Hi
>
> On 12/11/2012 12:15 PM, Peter Soetens wrote:
>> Hi Paul,
>>
>> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>>> Hello Peter.
>>>
>>> Some words about the last release :
>>>
>>> (1) Thank you for having managed this new release.
>>>
>>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
>>
>> There is an issue with the file server which caused all our new
>> uploads to be not available on the webserver. We've reported it and
>> hope it will be resolved soon. You can get rtt and ocl as archives
>> from github or gitorious. The complete toolchain we could try to
>> upload to a different place and see if we can manually move it on the
>> webserver...
>>
> I hope your Fiber channel controller won't cause too many problem to fixup.
It's fixed now. All downloads are accessible again.
>
>>>
>>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
>>
>> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
> Thank you.
>
>>
>>>
>>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
>>
>> What really sucks is that the rttlua deployer is called 'deployer' and
>> the taskbrowser deployer is called 'Deployer'. Changing either of
>> both is going to break a lot of scripts.
>>
>> Especially since every rttlua script contains a line like 'dp =
>> tc:getPeer("deployer")'
>>
>> What we could do is try to use the alias mechanism such that
>> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
>> official name as 'deployer' in rttlua*.
>>
>> For example (note that the DC is created as "deployer"):
>>
>> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
>> index 0a56197..22d03b9 100644
>> --- a/lua/LuaComponent.cpp
>> +++ b/lua/LuaComponent.cpp
>> @@ -345,6 +345,8 @@ int ORO_main(int argc, char** argv)
>> dc = new DeploymentComponent("deployer");
>>
>> lua.connectPeers(dc);
>> + // Alias for rttscript compatibility.
>> + lua.addPeer(dc, "Deployer");
>>
>> /* run init file */
>> wordexp(INIT_FILE, &init_exp, 0);
>>
>> Would this work for you ? Or is it also for the
>> CorbaDeploymentComponent + NamingService necessary ? How do you set
>> the the name of different CorbaDeploymentComponents ???
>
> I don't know if it would work for me... Charles Lesire is far more competent than me with lua stuff.
> But i suspect i will need the good name for the naming service. Please find my use case below...
>
> I used to name my components in the xml deployer config file :
>
>
> I also used to have one "root" node :
>
> Then, I launched the deployer with this root component as argument.
>
> On the remote control stataion, when I launch my GUI part, i need the name of the server plus the name of a component that will allow the GUI to discover all components running on the target.
>
Ok, so your deployment component name is not directly visible to outsiders.
>
> Now, i have simplified this mess, since :
> - i can omit the root component (and don't need to manage the naming of each deployment),
> - i can launch the deployer without additional arguments that change for each different deployment,
> - i can use the "Deployer" as the "root" component by default on the GUI side
... and here it's again visible :-)
>
> When i launch a lua Deployer, i need to override the default name of the "root component" with "deployer" instead of using the default "Deployer".
> Since i need to give the name of the deployer when i launch the gui for a lua deployment, i prefer to go back to my old method that give a name to each deployment.
>
> That why i suggested this homogenization.
Ok. Maybe a better alternative is to also extend rttlua with a --name
argument which allows to set the name of the deployment component,
identical to what the standard deployer allows...
>
>>
>>>
>>> (3) The bug 926 haven't been merged. Do you have suggestions to make the patch acceptable ?
>>
>> It was. I just assumed it had been merged already, and somehow also
>> overlooked the bug report. This is annoying since it adds a virtual
>> function to the ChannelElements. Is this patch in use on the rock-rtt
>> repository ?
>
> Why adding a virtual function to ChannelElements is annoying ? Is it about binary compatibility ?
Yes. It changes the virtual function table and would cause crashes if
not everything is nicely recompiled (in case of binary distribution of
components)
Peter
[Orocos] Orocos Toolchain 2.6.0 Released !
Agreed.
[Orocos] Orocos Toolchain 2.6.0 Released !
On Thu, Dec 13, 2012 at 10:20:09PM +0100, Peter Soetens wrote:
> On Tue, Dec 11, 2012 at 3:43 PM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
> > Hi
> >
> > On 12/11/2012 12:15 PM, Peter Soetens wrote:
> >> Hi Paul,
> >>
> >> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
> >>> Hello Peter.
> >>>
> >>> Some words about the last release :
> >>>
> >>> (1) Thank you for having managed this new release.
> >>>
> >>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
> >>
> >> There is an issue with the file server which caused all our new
> >> uploads to be not available on the webserver. We've reported it and
> >> hope it will be resolved soon. You can get rtt and ocl as archives
> >> from github or gitorious. The complete toolchain we could try to
> >> upload to a different place and see if we can manually move it on the
> >> webserver...
> >>
> > I hope your Fiber channel controller won't cause too many problem to fixup.
>
> It's fixed now. All downloads are accessible again.
>
> >
> >>>
> >>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
> >>
> >> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
> > Thank you.
> >
> >>
> >>>
> >>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
> >>
> >> What really sucks is that the rttlua deployer is called 'deployer' and
> >> the taskbrowser deployer is called 'Deployer'. Changing either of
> >> both is going to break a lot of scripts.
> >>
> >> Especially since every rttlua script contains a line like 'dp =
> >> tc:getPeer("deployer")'
> >>
> >> What we could do is try to use the alias mechanism such that
> >> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
> >> official name as 'deployer' in rttlua*.
> >>
> >> For example (note that the DC is created as "deployer"):
> >>
> >> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
> >> index 0a56197..22d03b9 100644
> >> --- a/lua/LuaComponent.cpp
> >> +++ b/lua/LuaComponent.cpp
> >> @@ -345,6 +345,8 @@ int ORO_main(int argc, char** argv)
> >> dc = new DeploymentComponent("deployer");
> >>
> >> lua.connectPeers(dc);
> >> + // Alias for rttscript compatibility.
> >> + lua.addPeer(dc, "Deployer");
> >>
> >> /* run init file */
> >> wordexp(INIT_FILE, &init_exp, 0);
> >>
> >> Would this work for you ? Or is it also for the
> >> CorbaDeploymentComponent + NamingService necessary ? How do you set
> >> the the name of different CorbaDeploymentComponents ???
> >
> > I don't know if it would work for me... Charles Lesire is far more competent than me with lua stuff.
> > But i suspect i will need the good name for the naming service. Please find my use case below...
> >
> > I used to name my components in the xml deployer config file :
> >
> >
> > I also used to have one "root" node :
> >
> > Then, I launched the deployer with this root component as argument.
> >
> > On the remote control stataion, when I launch my GUI part, i need the name of the server plus the name of a component that will allow the GUI to discover all components running on the target.
> >
>
> Ok, so your deployment component name is not directly visible to outsiders.
>
> >
> > Now, i have simplified this mess, since :
> > - i can omit the root component (and don't need to manage the naming of each deployment),
> > - i can launch the deployer without additional arguments that change for each different deployment,
> > - i can use the "Deployer" as the "root" component by default on the GUI side
>
> ... and here it's again visible :-)
>
> >
> > When i launch a lua Deployer, i need to override the default name of the "root component" with "deployer" instead of using the default "Deployer".
> > Since i need to give the name of the deployer when i launch the gui for a lua deployment, i prefer to go back to my old method that give a name to each deployment.
> >
> > That why i suggested this homogenization.
>
> Ok. Maybe a better alternative is to also extend rttlua with a --name
> argument which allows to set the name of the deployment component,
> identical to what the standard deployer allows...
I'm sorry for having introduced this mess, but lets not make it
worse. I suggest we just fix it, i.e. change the lua "deployer" to
"Deployer". This change will immediately bite you and require a
minimal an straightforward "one-char" fix. There's little danger it
will go unnoticed. Let's not drag this along any further.
Opinions?
Markus
[Orocos] Orocos Toolchain 2.6.0 Released !
On 14/12/2012, at 21:25 , Markus Klotzbuecher wrote:
> On Thu, Dec 13, 2012 at 10:20:09PM +0100, Peter Soetens wrote:
>> On Tue, Dec 11, 2012 at 3:43 PM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>>> Hi
>>>
>>> On 12/11/2012 12:15 PM, Peter Soetens wrote:
>>>> Hi Paul,
>>>>
>>>> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>>>>> Hello Peter.
>>>>>
>>>>> Some words about the last release :
>>>>>
>>>>> (1) Thank you for having managed this new release.
>>>>>
>>>>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
>>>>
>>>> There is an issue with the file server which caused all our new
>>>> uploads to be not available on the webserver. We've reported it and
>>>> hope it will be resolved soon. You can get rtt and ocl as archives
>>>> from github or gitorious. The complete toolchain we could try to
>>>> upload to a different place and see if we can manually move it on the
>>>> webserver...
>>>>
>>> I hope your Fiber channel controller won't cause too many problem to fixup.
>>
>> It's fixed now. All downloads are accessible again.
>>
>>>
>>>>>
>>>>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
>>>>
>>>> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
>>> Thank you.
>>>
>>>>
>>>>>
>>>>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
>>>>
>>>> What really sucks is that the rttlua deployer is called 'deployer' and
>>>> the taskbrowser deployer is called 'Deployer'. Changing either of
>>>> both is going to break a lot of scripts.
>>>>
>>>> Especially since every rttlua script contains a line like 'dp =
>>>> tc:getPeer("deployer")'
>>>>
>>>> What we could do is try to use the alias mechanism such that
>>>> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
>>>> official name as 'deployer' in rttlua*.
>>>>
>>>> For example (note that the DC is created as "deployer"):
>>>>
>>>> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
>>>> index 0a56197..22d03b9 100644
>>>> --- a/lua/LuaComponent.cpp
>>>> +++ b/lua/LuaComponent.cpp
>>>> @@ -345,6 +345,8 @@ int ORO_main(int argc, char** argv)
>>>> dc = new DeploymentComponent("deployer");
>>>>
>>>> lua.connectPeers(dc);
>>>> + // Alias for rttscript compatibility.
>>>> + lua.addPeer(dc, "Deployer");
>>>>
>>>> /* run init file */
>>>> wordexp(INIT_FILE, &init_exp, 0);
>>>>
>>>> Would this work for you ? Or is it also for the
>>>> CorbaDeploymentComponent + NamingService necessary ? How do you set
>>>> the the name of different CorbaDeploymentComponents ???
>>>
>>> I don't know if it would work for me... Charles Lesire is far more competent than me with lua stuff.
>>> But i suspect i will need the good name for the naming service. Please find my use case below...
>>>
>>> I used to name my components in the xml deployer config file :
>>>
>>>
>>> I also used to have one "root" node :
>>>
>>> Then, I launched the deployer with this root component as argument.
>>>
>>> On the remote control stataion, when I launch my GUI part, i need the name of the server plus the name of a component that will allow the GUI to discover all components running on the target.
>>>
>>
>> Ok, so your deployment component name is not directly visible to outsiders.
>>
>>>
>>> Now, i have simplified this mess, since :
>>> - i can omit the root component (and don't need to manage the naming of each deployment),
>>> - i can launch the deployer without additional arguments that change for each different deployment,
>>> - i can use the "Deployer" as the "root" component by default on the GUI side
>>
>> ... and here it's again visible :-)
>>
>>>
>>> When i launch a lua Deployer, i need to override the default name of the "root component" with "deployer" instead of using the default "Deployer".
>>> Since i need to give the name of the deployer when i launch the gui for a lua deployment, i prefer to go back to my old method that give a name to each deployment.
>>>
>>> That why i suggested this homogenization.
>>
>> Ok. Maybe a better alternative is to also extend rttlua with a --name
>> argument which allows to set the name of the deployment component,
>> identical to what the standard deployer allows...
>
> I'm sorry for having introduced this mess, but lets not make it
> worse. I suggest we just fix it, i.e. change the lua "deployer" to
> "Deployer". This change will immediately bite you and require a
> minimal an straightforward "one-char" fix. There's little danger it
> will go unnoticed. Let's not drag this along any further.
+1
Thanks for stepping up to solve this Markus
S
[Orocos] Orocos Toolchain 2.6.0 Released !
On Fri, Dec 14, 2012 at 9:25 AM, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> On Thu, Dec 13, 2012 at 10:20:09PM +0100, Peter Soetens wrote:
>> On Tue, Dec 11, 2012 at 3:43 PM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>> > Hi
>> >
>> > On 12/11/2012 12:15 PM, Peter Soetens wrote:
>> >> Hi Paul,
>> >>
>> >> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>> >>> Hello Peter.
>> >>>
>> >>> Some words about the last release :
>> >>>
>> >>> (1) Thank you for having managed this new release.
>> >>>
>> >>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
>> >>
>> >> There is an issue with the file server which caused all our new
>> >> uploads to be not available on the webserver. We've reported it and
>> >> hope it will be resolved soon. You can get rtt and ocl as archives
>> >> from github or gitorious. The complete toolchain we could try to
>> >> upload to a different place and see if we can manually move it on the
>> >> webserver...
>> >>
>> > I hope your Fiber channel controller won't cause too many problem to fixup.
>>
>> It's fixed now. All downloads are accessible again.
>>
>> >
>> >>>
>> >>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
>> >>
>> >> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
>> > Thank you.
>> >
>> >>
>> >>>
>> >>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
>> >>
>> >> What really sucks is that the rttlua deployer is called 'deployer' and
>> >> the taskbrowser deployer is called 'Deployer'. Changing either of
>> >> both is going to break a lot of scripts.
>> >>
>> >> Especially since every rttlua script contains a line like 'dp =
>> >> tc:getPeer("deployer")'
>> >>
>> >> What we could do is try to use the alias mechanism such that
>> >> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
>> >> official name as 'deployer' in rttlua*.
>> >>
>> >> For example (note that the DC is created as "deployer"):
>> >>
>> >> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
>> >> index 0a56197..22d03b9 100644
>> >> --- a/lua/LuaComponent.cpp
>> >> +++ b/lua/LuaComponent.cpp
>> >> @@ -345,6 +345,8 @@ int ORO_main(int argc, char** argv)
>> >> dc = new DeploymentComponent("deployer");
>> >>
>> >> lua.connectPeers(dc);
>> >> + // Alias for rttscript compatibility.
>> >> + lua.addPeer(dc, "Deployer");
>> >>
>> >> /* run init file */
>> >> wordexp(INIT_FILE, &init_exp, 0);
>> >>
>> >> Would this work for you ? Or is it also for the
>> >> CorbaDeploymentComponent + NamingService necessary ? How do you set
>> >> the the name of different CorbaDeploymentComponents ???
>> >
>> > I don't know if it would work for me... Charles Lesire is far more competent than me with lua stuff.
>> > But i suspect i will need the good name for the naming service. Please find my use case below...
>> >
>> > I used to name my components in the xml deployer config file :
>> >
>> >
>> > I also used to have one "root" node :
>> >
>> > Then, I launched the deployer with this root component as argument.
>> >
>> > On the remote control stataion, when I launch my GUI part, i need the name of the server plus the name of a component that will allow the GUI to discover all components running on the target.
>> >
>>
>> Ok, so your deployment component name is not directly visible to outsiders.
>>
>> >
>> > Now, i have simplified this mess, since :
>> > - i can omit the root component (and don't need to manage the naming of each deployment),
>> > - i can launch the deployer without additional arguments that change for each different deployment,
>> > - i can use the "Deployer" as the "root" component by default on the GUI side
>>
>> ... and here it's again visible :-)
>>
>> >
>> > When i launch a lua Deployer, i need to override the default name of the "root component" with "deployer" instead of using the default "Deployer".
>> > Since i need to give the name of the deployer when i launch the gui for a lua deployment, i prefer to go back to my old method that give a name to each deployment.
>> >
>> > That why i suggested this homogenization.
>>
>> Ok. Maybe a better alternative is to also extend rttlua with a --name
>> argument which allows to set the name of the deployment component,
>> identical to what the standard deployer allows...
>
> I'm sorry for having introduced this mess, but lets not make it
> worse. I suggest we just fix it, i.e. change the lua "deployer" to
> "Deployer". This change will immediately bite you and require a
> minimal an straightforward "one-char" fix. There's little danger it
> will go unnoticed. Let's not drag this along any further.
>
> Opinions?
+1
Ruben
> Markus
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
[Orocos] Orocos Toolchain 2.6.0 Released !
2012/12/14 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>:
> On Thu, Dec 13, 2012 at 10:20:09PM +0100, Peter Soetens wrote:
>> On Tue, Dec 11, 2012 at 3:43 PM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>> > Hi
>> >
>> > On 12/11/2012 12:15 PM, Peter Soetens wrote:
>> >> Hi Paul,
>> >>
>> >> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>> >>> Hello Peter.
>> >>>
>> >>> Some words about the last release :
>> >>>
>> >>> (1) Thank you for having managed this new release.
>> >>>
>> >>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
>> >>
>> >> There is an issue with the file server which caused all our new
>> >> uploads to be not available on the webserver. We've reported it and
>> >> hope it will be resolved soon. You can get rtt and ocl as archives
>> >> from github or gitorious. The complete toolchain we could try to
>> >> upload to a different place and see if we can manually move it on the
>> >> webserver...
>> >>
>> > I hope your Fiber channel controller won't cause too many problem to fixup.
>>
>> It's fixed now. All downloads are accessible again.
>>
>> >
>> >>>
>> >>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
>> >>
>> >> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
>> > Thank you.
>> >
>> >>
>> >>>
>> >>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
>> >>
>> >> What really sucks is that the rttlua deployer is called 'deployer' and
>> >> the taskbrowser deployer is called 'Deployer'. Changing either of
>> >> both is going to break a lot of scripts.
>> >>
>> >> Especially since every rttlua script contains a line like 'dp =
>> >> tc:getPeer("deployer")'
>> >>
>> >> What we could do is try to use the alias mechanism such that
>> >> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
>> >> official name as 'deployer' in rttlua*.
>> >>
>> >> For example (note that the DC is created as "deployer"):
>> >>
>> >> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
>> >> index 0a56197..22d03b9 100644
>> >> --- a/lua/LuaComponent.cpp
>> >> +++ b/lua/LuaComponent.cpp
>> >> @@ -345,6 +345,8 @@ int ORO_main(int argc, char** argv)
>> >> dc = new DeploymentComponent("deployer");
>> >>
>> >> lua.connectPeers(dc);
>> >> + // Alias for rttscript compatibility.
>> >> + lua.addPeer(dc, "Deployer");
>> >>
>> >> /* run init file */
>> >> wordexp(INIT_FILE, &init_exp, 0);
>> >>
>> >> Would this work for you ? Or is it also for the
>> >> CorbaDeploymentComponent + NamingService necessary ? How do you set
>> >> the the name of different CorbaDeploymentComponents ???
>> >
>> > I don't know if it would work for me... Charles Lesire is far more competent than me with lua stuff.
>> > But i suspect i will need the good name for the naming service. Please find my use case below...
>> >
>> > I used to name my components in the xml deployer config file :
>> >
>> >
>> > I also used to have one "root" node :
>> >
>> > Then, I launched the deployer with this root component as argument.
>> >
>> > On the remote control stataion, when I launch my GUI part, i need the name of the server plus the name of a component that will allow the GUI to discover all components running on the target.
>> >
>>
>> Ok, so your deployment component name is not directly visible to outsiders.
>>
>> >
>> > Now, i have simplified this mess, since :
>> > - i can omit the root component (and don't need to manage the naming of each deployment),
>> > - i can launch the deployer without additional arguments that change for each different deployment,
>> > - i can use the "Deployer" as the "root" component by default on the GUI side
>>
>> ... and here it's again visible :-)
>>
>> >
>> > When i launch a lua Deployer, i need to override the default name of the "root component" with "deployer" instead of using the default "Deployer".
>> > Since i need to give the name of the deployer when i launch the gui for a lua deployment, i prefer to go back to my old method that give a name to each deployment.
>> >
>> > That why i suggested this homogenization.
>>
>> Ok. Maybe a better alternative is to also extend rttlua with a --name
>> argument which allows to set the name of the deployment component,
>> identical to what the standard deployer allows...
>
> I'm sorry for having introduced this mess, but lets not make it
> worse. I suggest we just fix it, i.e. change the lua "deployer" to
> "Deployer". This change will immediately bite you and require a
> minimal an straightforward "one-char" fix. There's little danger it
> will go unnoticed. Let's not drag this along any further.
>
> Opinions?
+1, don't let this continue to cause problems, it'll be worse and
worse, it is not so heavy to replace "deployer" in "Deployer" in
existing code.
>
> Markus
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
[Orocos] Orocos Toolchain 2.6.0 Released !
On Tue, 11 Dec 2012, Peter Soetens wrote:
> Hi Paul,
>
> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>> Hello Peter.
>>
>> Some words about the last release :
>>
>> (1) Thank you for having managed this new release.
>>
>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
>
> There is an issue with the file server
Fibre channel controller of our SAN broke down.... :-(((
Herman
> which caused all our new
> uploads to be not available on the webserver. We've reported it and
> hope it will be resolved soon. You can get rtt and ocl as archives
> from github or gitorious. The complete toolchain we could try to
> upload to a different place and see if we can manually move it on the
> webserver...
>
>>
>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
>
> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
>
>>
>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
>
> What really sucks is that the rttlua deployer is called 'deployer' and
> the taskbrowser deployer is called 'Deployer'. Changing either of
> both is going to break a lot of scripts.
>
> Especially since every rttlua script contains a line like 'dp =
> tc:getPeer("deployer")'
>
> What we could do is try to use the alias mechanism such that
> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
> official name as 'deployer' in rttlua*.
>
> For example (note that the DC is created as "deployer"):
>
> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
> index 0a56197..22d03b9 100644
[Orocos] Orocos Toolchain 2.6.0 Released !
On Tue, 11 Dec 2012, Peter Soetens wrote:
> Hi Paul,
>
> On Tue, Dec 11, 2012 at 11:09 AM, Paul Chavent <paul [dot] chavent [..] ...> wrote:
>> Hello Peter.
>>
>> Some words about the last release :
>>
>> (1) Thank you for having managed this new release.
>>
>> (2) The downloads of the archives didn't work today : http://people.mech.kuleuven.be/~orocos/pub/stable/toolchain/v2.6.0/oroco... returns 404. Is it still possible to access independent archives of rtt and ocl ?
>
> There is an issue with the file server
Fibre channel controller of our SAN broke down.... :-(((
Herman
> which caused all our new
> uploads to be not available on the webserver. We've reported it and
> hope it will be resolved soon. You can get rtt and ocl as archives
> from github or gitorious. The complete toolchain we could try to
> upload to a different place and see if we can manually move it on the
> webserver...
>
>>
>> (3) I'm sorry, but i have submitted a wrong patch for the bug 979. I thought that you have read my comment http://bugs.orocos.org/show_bug.cgi?id=979#c6 , but the master repo still contains the error (a class keyword to replace by a struct).
>
> I did, but then I forgot.. patch is king :-) Fixed on gitorious.
>
>>
>> (4) The bug 950 have been partially merged. I added some modifications (see http://bugs.orocos.org/show_bug.cgi?id=950#c8). Do you have some reviews on it ?
>
> What really sucks is that the rttlua deployer is called 'deployer' and
> the taskbrowser deployer is called 'Deployer'. Changing either of
> both is going to break a lot of scripts.
>
> Especially since every rttlua script contains a line like 'dp =
> tc:getPeer("deployer")'
>
> What we could do is try to use the alias mechanism such that
> 'deployer' and 'Deployer' resolve to the same TC, *but keep the
> official name as 'deployer' in rttlua*.
>
> For example (note that the DC is created as "deployer"):
>
> diff --git a/lua/LuaComponent.cpp b/lua/LuaComponent.cpp
> index 0a56197..22d03b9 100644
Orocos Toolchain 2.6.0 Released !
2012/12/3 Peter Soetens <peter [..] ...>:
> The Orocos Toolchain developers are content[1] to announce the 2.6
> release cycle of the Orocos Toolchain. As in the previous release
> cycle, the emphasis is on stability, incremental development and
> stable API's. The major additions in this release are:
> - stable typekits: we can now load typekits from all kinds of sources
> (hand written, ROS, yaml, typegen,...) without having conflicts in
> names or functionality
> - RTT added a CIRCULAR_BUFFER connection policy: drops oldest sample
> instead of newest
> - Revamped OCL reporter with NetCDF support: reporting is now about
> 100-1000 times faster / less cpu intensive than before - and is
> compatible and more efficient with KST2
> - Updated orogen component generation framework
> - C++ runaway exceptions in operations are now caught by RTT and
> bring your component to the Exception state.
> - Many updates to deployment: allow to connect provides() and
> requires() operations, have shutdown and daemon support.
> - Improved tlsf, logging and corba support for rttlua
>
> Under the hood, these changes make a difference too:
> - We achieved hard real-time operation calls for rttlua-tlsf: due to
> stable typekits, we can now do typeinfo caching eliminating the last
> source of memory allocations and improving performance.
> - We log PID/TID numbers on Linux systems when Activity objects are
> created, such that you can relate to them using 'top'.
> - We mutex-lock the TypeInfoRepository to allow multi-threaded
> imports of typekits (typically in iTaSC / rttlua apps)
> - We moved the component loader to RTT such that you don't need OCL
> to load components in applications.
>
> Some more details can be found on the 2.6 Release notes here:
> http://www.orocos.org/stable/documentation/rtt/v2.6.x/doc-xml/orocos-rtt...
>
> You can download this release using the bootstrap script on the
> website, or pointing your autoproj configuration to the toolchain-2.6
> branch, or by fetching the ROS Fuerte Ubuntu packages.
>
> http://www.orocos.org/wiki/orocos/toolchain/quick-start
>
> Since the majority of the Orocos users uses one of these three
> methods, it remains to be seen if a 'dot' release will be made.
> I would only do so to communicate to newcomers that we do make
> bugfixes on a regular basis.
>
> Thanks to the many Orocos users and developers who have contributed to
> this truely major release.
>
> Peter
>
> [1] adjective : satisfied with what one is or has; not wanting more or
> anything else.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
\o/
There is so many interesting things :D