Please have a look at this enclosed patch (note that I did my best to
play with git, crossed fingers...). Generated with :
git format-patch origin/toolchain-2.5

This is what I did :
_ conversing the argument parsing to boost::program_option into a
separated parseArgs function
_ add a default "Deployer" value of the researched Proxy
_ updated the README
_ add boost_program_option libraries to ctaskbrowser linked libraries
_ add a new readScript function that is supposed to read an ops (or an
xml if it doesn't cost much to implement) for typekits loading.

I have doubts of what I am doing then. In a standard deployer the
runScript function is done by the Deployer TaskContext. Here I just
have a proxy, should I really use the scripting->runScript function in
it ? I succeeded in adding the Scripting service to the proxy but it
doesn't seem to read it (cause I can type any bullshit in it it
doesn't complain).

I think I can take the occasion to add the log Level option of
classical Deployer, what do you think of that ?

2012/3/29, Willy Lambert <lambert [dot] willy [..] ...>:
> 2012/3/29 Willy Lambert <lambert [dot] willy [..] ...>:
>> 2012/3/29 Peter Soetens <peter [..] ...>:
>>> On Thu, Mar 29, 2012 at 10:58 AM, Willy Lambert <lambert [dot] willy [..] ...>
>>> wrote:
>>>> Hi,
>>>>
>>>> I successfully deployed an application with the deployer-corba
>>>> application, and I am starting to browse its components with the
>>>> ctaskbrowser. Some thing are working, some are not. In particular I
>>>> have this warning when launching the ctaskbrowser :
>>>
>>> The problem with the ctaskbrowser is that it can not import typekits
>>> 'on command'. So it has only the RTT_COMPONENT_PATH to look for
>>> automatically loading typekits. Any typekit in this path will be
>>> loaded by the ctaskbrowser. The normal deployer does not have this
>>> issue because you instruct it to load a typekit explicitly using
>>> 'import'.
>>>
>>>>
>>>>
>>>> ard@ard-host(9.1):/opt/ros_addons/orocos_toolchain/ocl/bin$
>>>> ./ctaskbrowser HmlMonitor -ORBInitRef
>>>> NameService=corbaloc:iiop:192.168.1.41:2809/NameService
>>>> 0.028 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>>>> non-privileged users..
>>>> 0.028 [ Warning][Activity] Lowering scheduler type to SCHED_OTHER for
>>>> non-privileged users..
>>>> 0.090 [ ERROR ][OrbRunner] Looked up Property float64
>>>> propCanRequestTimeout: type not known. Check your RTT_COMPONENT_PATH.
>>>>
>>>> TaskBrowser connects to all data ports of HmlMonitor
>>>> 0.466 [ Warning][Thread] Lowering scheduler type to SCHED_OTHER for
>>>> non-privileged users..
>>>> 0.466 [ Warning][TaskBrowser.CorbaDispatch] Lowering scheduler type to
>>>> SCHED_OTHER for non-privileged users..
>>>> Switched to : HmlMonitor
>>>>
>>>>
>>>> So I checked my RTT_COMPONENT_PATH which is empty. As I am using the
>>>> ROS installation of the toolchain it may be related.
>>>>
>>>>
>>>> I don't know if this is related but I also have for ages this warning
>>>> in my normal deployer (on both computers tried in the Corba network) :
>>>> root@beta(9.1):/opt/ard/arp_hml# rosrun ocl deployer-corba-gnulinux -s
>>>> /opt/ard/arp_hml/script/orocos/deployment/deploy_ubiquity.ops
>>>> 0.130 [ Warning][DeploymentComponent::import] The ROS package 'ocl' in
>>>> '/opt/ros_addons/orocos_toolchain/ocl' nor its dependencies contained
>>>> a lib/orocos directory. I'll look in the RTT_COMPONENT_PATH next.
>>>>
>>>> and RTT_COMPONENT_PATH is still empty but nothing complain and I can
>>>> use my stuff anyway.
>>>
>>> We need to get rid of this warning :-)
>>>
>>>>
>>>>
>>>> Should I force the RTT_COMPONENT_PATH ?
>>>
>>> For the ctaskbrowser, yes.
>>
>> What should I put here then ? rtt+ocl+my packages paths ?
>> what is a RTT_COMPONENT_PATH ? the path to package/lib ? or
>> package/lib/orocos ? or something else ?
>>
>> We could also invent a -s option that loads
>>> a script/xml file which imports the necessary typekits.
>>>
>
> I'll try something. I suggest to do a proper boost::program_option
> management of cmd line arguments aka :
> _ introduce a -n --name option for the IOR/ComponentName (currently it
> is the only functionnal option)
> _ introduce a -s --start option for reading a script/XML file.
> _ maintain the -v --version and -h --help options already existing.
>
> taking as a model the deployer-funcs.cpp deployerParseCmdLine function.
>
> Then I'll try do implement the -s function reading and I'll be back
> for questions I think ^^
>
>>> Peter
>