[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] [Orocos-users] [Orocos] Orocos Toolchain 2.6.0 Released !
From:       kiwi.net () mac ! com (S Roderick)
Date:       2012-12-14 19:06:53
Message-ID: F9F43C82-AE0C-4ED4-8B16-24A9415292A3 () mac ! com
[Download RAW message or body]

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.chavent at fnac.net> 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.chavent at fnac.net> \
> > > > 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


[prev in list] [next in list] [prev in thread] [next in thread]