Re: [Orocos-users] [Orocos] Orocos Toolchain 2.6.0 Released !
S Roderick <[email protected]>
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 <[email protected]> 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/orocos-toolchain-2.6.0-src.tar.bz2 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 : >>> [code] >>> <struct name="ObcRmax" type="Talc::Avionique::Orocos::ObcRmax"> >>> <simple name="Server" type="boolean"><value>1</value></simple> >>> ... >>> </struct> >>> [/code] >>> >>> I also used to have one "root" node : >>> [code] >>> <struct name="Avionique"></struct> >>> [/code] >>> 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. >>> [code] >>> RTT::corba::TaskContextFactory::InitOrb(argc, argv); // connect to the remote target >>> RTT::corba::TaskContextFactory::Create("Avionique"); // get the "root" component >>> [/code] >> >> 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-Dev mailing list [email protected] http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev