Hi, I've found that deployer can load plugin at start up. All plugins found in "/usr/lib/rtt/gnulinux/plugins" according to this bug/feature. With corba this issus is properly load according to the orocos.log when deploying with cdeployer:
0.002 [ Info ][cdeployer-gnulinux::main()] Loading plugins from /usr/lib/rtt/gnulinux/plugins 0.002 [ Debug ][DeploymentComponent::import] Importing /usr/lib/rtt/gnulinux/plugins 0.002 [ Debug ][DeploymentComponent::import] Scanning /usr/lib/rtt/gnulinux/plugins/libCablesToolKit.so 0.002 [ Debug ][DeploymentComponent::import] Accepting libCablesToolKit.so
When using the ctaskbrowser, the plugin doesn`t seem to be load. In this case, the plugin create new type to be used with the templated Property class. The ctaskbrowser load sucessfully but when you list a componant with plugin type, you get the following message:
237.778 [ ERROR ][TypeInfoName] Looking up Property CornerCubeCan not build Property of unknown_t.
Can someone help me?
Thanks a lot!
Plugin with ctaskbrowser
On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
> Hi, I've found that deployer can load plugin at start up. All plugins found in "/usr/lib/rtt/gnulinux/plugins" according to this [http://orocos.org/node/551 bug/feature].
> With corba this issus is properly load according to the orocos.log when deploying with cdeployer:
>
>
> When using the ctaskbrowser, the plugin doesn`t seem to be load.
This is because of a flaw in the current architecture. It's the
DeploymentComponent that loads the plugins, since the ctaskbrowser
application does not have that component, it won't look for plugins.
You can solve this by using the deployer-corba-gnulinux application
instead of the ctaskbrowser.
You can then connect to a remote component typing
loadComponent("Name","CORBA") at the TB
prompt. Alternatives are loadComponent("IOR:...","IOR") and
loadComponent("name.ior","IORFile")
Peter
Plugin with ctaskbrowser
On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>> Hi, I've found that deployer can load plugin at start up. All
>> plugins found in "/usr/lib/rtt/gnulinux/plugins" according to this [http://orocos.org/node/551
>> bug/feature].
>> With corba this issus is properly load according to the orocos.log
>> when deploying with cdeployer:
>>
>>
>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>
> This is because of a flaw in the current architecture. It's the
> DeploymentComponent that loads the plugins, since the ctaskbrowser
> application does not have that component, it won't look for plugins.
>
> You can solve this by using the deployer-corba-gnulinux application
> instead of the ctaskbrowser.
> You can then connect to a remote component typing
> loadComponent("Name","CORBA") at the TB
> prompt. Alternatives are loadComponent("IOR:...","IOR") and
> loadComponent("name.ior","IORFile")
That still won't load the plugins though, will it Peter? Or are you
thinking that they'll feed the 2nd deployer a file listing which
libraries/plugins to load? Or manually type in loadLibrary() commands?
Stephen
Plugin with ctaskbrowser
On Fri, Jun 12, 2009 at 14:10, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> So not trying to merge ctaskbrowser and deployer for v1.x, just making
> ctaskbrowswer plugin aware?
Yes.
Plugin with ctaskbrowser
On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...> wrote:
> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>
>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>
>>> Hi, I've found that deployer can load plugin at start up. All plugins
>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>> [http://orocos.org/node/551 bug/feature].
>>> With corba this issus is properly load according to the orocos.log when
>>> deploying with cdeployer:
>>>
>>>
>>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>>
>> This is because of a flaw in the current architecture. It's the
>> DeploymentComponent that loads the plugins, since the ctaskbrowser
>> application does not have that component, it won't look for plugins.
>>
>> You can solve this by using the deployer-corba-gnulinux application
>> instead of the ctaskbrowser.
>> You can then connect to a remote component typing
>> loadComponent("Name","CORBA") at the TB
>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>> loadComponent("name.ior","IORFile")
>
> That still won't load the plugins though, will it Peter? Or are you thinking
> that they'll feed the 2nd deployer a file listing which libraries/plugins to
> load? Or manually type in loadLibrary() commands?
The DeploymentComponent in 1.8 does a this->configure() in the constructor,
and thus searches for plugins. If you wrote your type registration and corba
transports as plugins, they should be loaded, shouldn't they? I need to look
the exact semantics up again though...
Peter
Plugin with ctaskbrowser
On Jun 11, 2009, at 16:01 , Peter Soetens wrote:
> On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...> wrote:
>> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>>
>>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>>
>>>> Hi, I've found that deployer can load plugin at start up. All
>>>> plugins
>>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>>> [http://orocos.org/node/551 bug/feature].
>>>> With corba this issus is properly load according to the
>>>> orocos.log when
>>>> deploying with cdeployer:
>>>>
>>>>
>>>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>>>
>>> This is because of a flaw in the current architecture. It's the
>>> DeploymentComponent that loads the plugins, since the ctaskbrowser
>>> application does not have that component, it won't look for plugins.
>>>
>>> You can solve this by using the deployer-corba-gnulinux application
>>> instead of the ctaskbrowser.
>>> You can then connect to a remote component typing
>>> loadComponent("Name","CORBA") at the TB
>>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>>> loadComponent("name.ior","IORFile")
>>
>> That still won't load the plugins though, will it Peter? Or are you
>> thinking
>> that they'll feed the 2nd deployer a file listing which libraries/
>> plugins to
>> load? Or manually type in loadLibrary() commands?
>
> The DeploymentComponent in 1.8 does a this->configure() in the
> constructor,
> and thus searches for plugins. If you wrote your type registration
> and corba
> transports as plugins, they should be loaded, shouldn't they? I need
> to look
> the exact semantics up again though...
Ok, didn't know that. Any way to specify the path for plugins yet?
S
Plugin with ctaskbrowser
On Thu, Jun 11, 2009 at 22:04, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
>
> On Jun 11, 2009, at 16:01 , Peter Soetens wrote:
>
>> On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>
>>> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>>>
>>>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>>>
>>>>> Hi, I've found that deployer can load plugin at start up. All plugins
>>>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>>>> [http://orocos.org/node/551 bug/feature].
>>>>> With corba this issus is properly load according to the orocos.log when
>>>>> deploying with cdeployer:
>>>>>
>>>>>
>>>>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>>>>
>>>> This is because of a flaw in the current architecture. It's the
>>>> DeploymentComponent that loads the plugins, since the ctaskbrowser
>>>> application does not have that component, it won't look for plugins.
>>>>
>>>> You can solve this by using the deployer-corba-gnulinux application
>>>> instead of the ctaskbrowser.
>>>> You can then connect to a remote component typing
>>>> loadComponent("Name","CORBA") at the TB
>>>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>>>> loadComponent("name.ior","IORFile")
>>>
>>> That still won't load the plugins though, will it Peter? Or are you
>>> thinking
>>> that they'll feed the 2nd deployer a file listing which libraries/plugins
>>> to
>>> load? Or manually type in loadLibrary() commands?
>>
>> The DeploymentComponent in 1.8 does a this->configure() in the
>> constructor,
>> and thus searches for plugins. If you wrote your type registration and
>> corba
>> transports as plugins, they should be loaded, shouldn't they? I need to
>> look
>> the exact semantics up again though...
>
> Ok, didn't know that. Any way to specify the path for plugins yet?
I had a patch for this, but it seems I didn't merge it. I've attached it.
The idea is that you can specify a site XML file which allows you
to preload and pre-configure some components. This XML file is by
default named 'Deployer-site.cpf'. There you can add import statements,
set the ComponentPath etc.
I believe the final consensus was that ComponentPath and PluginPath should
be a) lists of paths that b) can be set by environment variables. The site-file
is complementary to this that it allows to set these paths from the XML file
instead of the environment.
YYMV(*)
Peter
(*)Your YAGNI May Vary
Plugin with ctaskbrowser
On Jun 11, 2009, at 16:55 , Peter Soetens wrote:
> On Thu, Jun 11, 2009 at 22:04, Stephen Roderick<kiwi [dot] net [..] ...>
> wrote:
>>
>> On Jun 11, 2009, at 16:01 , Peter Soetens wrote:
>>
>>> On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>
>>>> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>>>>
>>>>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>>>>
>>>>>> Hi, I've found that deployer can load plugin at start up. All
>>>>>> plugins
>>>>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>>>>> [http://orocos.org/node/551 bug/feature].
>>>>>> With corba this issus is properly load according to the
>>>>>> orocos.log when
>>>>>> deploying with cdeployer:
>>>>>>
>>>>>>
>>>>>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>>>>>
>>>>> This is because of a flaw in the current architecture. It's the
>>>>> DeploymentComponent that loads the plugins, since the ctaskbrowser
>>>>> application does not have that component, it won't look for
>>>>> plugins.
>>>>>
>>>>> You can solve this by using the deployer-corba-gnulinux
>>>>> application
>>>>> instead of the ctaskbrowser.
>>>>> You can then connect to a remote component typing
>>>>> loadComponent("Name","CORBA") at the TB
>>>>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>>>>> loadComponent("name.ior","IORFile")
>>>>
>>>> That still won't load the plugins though, will it Peter? Or are you
>>>> thinking
>>>> that they'll feed the 2nd deployer a file listing which libraries/
>>>> plugins
>>>> to
>>>> load? Or manually type in loadLibrary() commands?
>>>
>>> The DeploymentComponent in 1.8 does a this->configure() in the
>>> constructor,
>>> and thus searches for plugins. If you wrote your type registration
>>> and
>>> corba
>>> transports as plugins, they should be loaded, shouldn't they? I
>>> need to
>>> look
>>> the exact semantics up again though...
>>
>> Ok, didn't know that. Any way to specify the path for plugins yet?
>
> I had a patch for this, but it seems I didn't merge it. I've
> attached it.
> The idea is that you can specify a site XML file which allows you
> to preload and pre-configure some components. This XML file is by
> default named 'Deployer-site.cpf'. There you can add import
> statements,
> set the ComponentPath etc.
>
> I believe the final consensus was that ComponentPath and PluginPath
> should
> be a) lists of paths that b) can be set by environment variables.
> The site-file
> is complementary to this that it allows to set these paths from the
> XML file
> instead of the environment.
>
> YYMV(*)
>
> Peter
>
> (*)Your YAGNI May Vary
> <site-file-for-deployer.patch>
Will this be integrated into trunk at some point? Vastly prefer
dealing with it that way, rather than keeping patches around. Anyway,
this doesn't appear to change any behaviour so merging it doesn't
sound terrible?
Plugin with ctaskbrowser
On Jun 11, 2009, at 16:55 , Peter Soetens wrote:
> On Thu, Jun 11, 2009 at 22:04, Stephen Roderick<kiwi [dot] net [..] ...>
> wrote:
>>
>> On Jun 11, 2009, at 16:01 , Peter Soetens wrote:
>>
>>> On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>
>>>> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>>>>
>>>>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>>>>
>>>>>> Hi, I've found that deployer can load plugin at start up. All
>>>>>> plugins
>>>>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>>>>> [http://orocos.org/node/551 bug/feature].
>>>>>> With corba this issus is properly load according to the
>>>>>> orocos.log when
>>>>>> deploying with cdeployer:
>>>>>>
>>>>>>
>>>>>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>>>>>
>>>>> This is because of a flaw in the current architecture. It's the
>>>>> DeploymentComponent that loads the plugins, since the ctaskbrowser
>>>>> application does not have that component, it won't look for
>>>>> plugins.
>>>>>
>>>>> You can solve this by using the deployer-corba-gnulinux
>>>>> application
>>>>> instead of the ctaskbrowser.
>>>>> You can then connect to a remote component typing
>>>>> loadComponent("Name","CORBA") at the TB
>>>>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>>>>> loadComponent("name.ior","IORFile")
>>>>
>>>> That still won't load the plugins though, will it Peter? Or are you
>>>> thinking
>>>> that they'll feed the 2nd deployer a file listing which libraries/
>>>> plugins
>>>> to
>>>> load? Or manually type in loadLibrary() commands?
>>>
>>> The DeploymentComponent in 1.8 does a this->configure() in the
>>> constructor,
>>> and thus searches for plugins. If you wrote your type registration
>>> and
>>> corba
>>> transports as plugins, they should be loaded, shouldn't they? I
>>> need to
>>> look
>>> the exact semantics up again though...
>>
>> Ok, didn't know that. Any way to specify the path for plugins yet?
>
> I had a patch for this, but it seems I didn't merge it. I've
> attached it.
> The idea is that you can specify a site XML file which allows you
> to preload and pre-configure some components. This XML file is by
> default named 'Deployer-site.cpf'. There you can add import
> statements,
> set the ComponentPath etc.
>
> I believe the final consensus was that ComponentPath and PluginPath
> should
> be a) lists of paths that b) can be set by environment variables.
> The site-file
> is complementary to this that it allows to set these paths from the
> XML file
> instead of the environment.
>
> YYMV(*)
>
> Peter
>
> (*)Your YAGNI May Vary
> <site-file-for-deployer.patch>
Thinking about it, is there anything stopping us adding this
functionality as an option directly into "ctaskbrowser"? It would be
the only OCL program that doesn't benefit from the above, right? This
way all OCL programs would be consistent.
Plugin with ctaskbrowser
On Fri, Jun 12, 2009 at 02:13, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
> On Jun 11, 2009, at 16:55 , Peter Soetens wrote:
>
>> On Thu, Jun 11, 2009 at 22:04, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
>>>
>>> On Jun 11, 2009, at 16:01 , Peter Soetens wrote:
>>>
>>>> On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>>
>>>>> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>>>>>
>>>>>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>>>>>
>>>>>>> Hi, I've found that deployer can load plugin at start up. All plugins
>>>>>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>>>>>> [http://orocos.org/node/551 bug/feature].
>>>>>>> With corba this issus is properly load according to the orocos.log
>>>>>>> when
>>>>>>> deploying with cdeployer:
>>>>>>>
>>>>>>>
>>>>>>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>>>>>>
>>>>>> This is because of a flaw in the current architecture. It's the
>>>>>> DeploymentComponent that loads the plugins, since the ctaskbrowser
>>>>>> application does not have that component, it won't look for plugins.
>>>>>>
>>>>>> You can solve this by using the deployer-corba-gnulinux application
>>>>>> instead of the ctaskbrowser.
>>>>>> You can then connect to a remote component typing
>>>>>> loadComponent("Name","CORBA") at the TB
>>>>>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>>>>>> loadComponent("name.ior","IORFile")
>>>>>
>>>>> That still won't load the plugins though, will it Peter? Or are you
>>>>> thinking
>>>>> that they'll feed the 2nd deployer a file listing which
>>>>> libraries/plugins
>>>>> to
>>>>> load? Or manually type in loadLibrary() commands?
>>>>
>>>> The DeploymentComponent in 1.8 does a this->configure() in the
>>>> constructor,
>>>> and thus searches for plugins. If you wrote your type registration and
>>>> corba
>>>> transports as plugins, they should be loaded, shouldn't they? I need to
>>>> look
>>>> the exact semantics up again though...
>>>
>>> Ok, didn't know that. Any way to specify the path for plugins yet?
>>
>> I had a patch for this, but it seems I didn't merge it. I've attached it.
>> The idea is that you can specify a site XML file which allows you
>> to preload and pre-configure some components. This XML file is by
>> default named 'Deployer-site.cpf'. There you can add import statements,
>> set the ComponentPath etc.
>>
>> I believe the final consensus was that ComponentPath and PluginPath should
>> be a) lists of paths that b) can be set by environment variables. The
>> site-file
>> is complementary to this that it allows to set these paths from the XML
>> file
>> instead of the environment.
>>
>> YYMV(*)
>>
>> Peter
>>
>> (*)Your YAGNI May Vary
>> <site-file-for-deployer.patch>
>
> Thinking about it, is there anything stopping us adding this functionality
> as an option directly into "ctaskbrowser"? It would be the only OCL program
> that doesn't benefit from the above, right? This way all OCL programs would
> be consistent.
You're right. Just adding a (hidden) DeploymentComponent to
ctaskbrowser that does the site-loading
would fix this whole issue.
This would make ctaskbrowser almost identical to deployer-corba-gnulinux,
except that ctaskbrowser connects to a remote component immediately
Maybe the best way is to merge ctaskbrowser and deployer-corba-gnulinux
into one tool ? What's the typical usage scenario (you'd like) ?
Peter
Plugin with ctaskbrowser
On Fri, 12 Jun 2009, Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 02:13, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
>> On Jun 11, 2009, at 16:55 , Peter Soetens wrote:
>>
>>> On Thu, Jun 11, 2009 at 22:04, Stephen Roderick<kiwi [dot] net [..] ...> wrote:
>>>>
>>>> On Jun 11, 2009, at 16:01 , Peter Soetens wrote:
>>>>
>>>>> On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...> wrote:
>>>>>>
>>>>>> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>>>>>>
>>>>>>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>>>>>>
>>>>>>>> Hi, I've found that deployer can load plugin at start up. All plugins
>>>>>>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>>>>>>> [http://orocos.org/node/551 bug/feature].
>>>>>>>> With corba this issus is properly load according to the orocos.log
>>>>>>>> when
>>>>>>>> deploying with cdeployer:
>>>>>>>>
>>>>>>>>
>>>>>>>> When using the ctaskbrowser, the plugin doesn`t seem to be load.
>>>>>>>
>>>>>>> This is because of a flaw in the current architecture. It's the
>>>>>>> DeploymentComponent that loads the plugins, since the ctaskbrowser
>>>>>>> application does not have that component, it won't look for plugins.
>>>>>>>
>>>>>>> You can solve this by using the deployer-corba-gnulinux application
>>>>>>> instead of the ctaskbrowser.
>>>>>>> You can then connect to a remote component typing
>>>>>>> loadComponent("Name","CORBA") at the TB
>>>>>>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>>>>>>> loadComponent("name.ior","IORFile")
>>>>>>
>>>>>> That still won't load the plugins though, will it Peter? Or are you
>>>>>> thinking
>>>>>> that they'll feed the 2nd deployer a file listing which
>>>>>> libraries/plugins
>>>>>> to
>>>>>> load? Or manually type in loadLibrary() commands?
>>>>>
>>>>> The DeploymentComponent in 1.8 does a this->configure() in the
>>>>> constructor,
>>>>> and thus searches for plugins. If you wrote your type registration and
>>>>> corba
>>>>> transports as plugins, they should be loaded, shouldn't they? I need to
>>>>> look
>>>>> the exact semantics up again though...
>>>>
>>>> Ok, didn't know that. Any way to specify the path for plugins yet?
>>>
>>> I had a patch for this, but it seems I didn't merge it. I've attached it.
>>> The idea is that you can specify a site XML file which allows you
>>> to preload and pre-configure some components. This XML file is by
>>> default named 'Deployer-site.cpf'. There you can add import statements,
>>> set the ComponentPath etc.
>>>
>>> I believe the final consensus was that ComponentPath and PluginPath should
>>> be a) lists of paths that b) can be set by environment variables. The
>>> site-file
>>> is complementary to this that it allows to set these paths from the XML
>>> file
>>> instead of the environment.
>>>
>>> YYMV(*)
>>>
>>> Peter
>>>
>>> (*)Your YAGNI May Vary
>>> <site-file-for-deployer.patch>
>>
>> Thinking about it, is there anything stopping us adding this functionality
>> as an option directly into "ctaskbrowser"? It would be the only OCL program
>> that doesn't benefit from the above, right? This way all OCL programs would
>> be consistent.
>
> You're right. Just adding a (hidden) DeploymentComponent to
> ctaskbrowser that does the site-loading
> would fix this whole issue.
>
> This would make ctaskbrowser almost identical to deployer-corba-gnulinux,
> except that ctaskbrowser connects to a remote component immediately
> Maybe the best way is to merge ctaskbrowser and deployer-corba-gnulinux
> into one tool ? What's the typical usage scenario (you'd like) ?
Interesting suggestion...! Can you state explicitly what the real semantics
are of both concepts (the "new" ctaskbrowser and the
deployer-corba-gnulinux)? If these semantics match, it is indeed a good
opportunity to merge them, into something with an appropriate name, and
with both (or more) "use cases" as configurable properties...
Herman
Plugin with ctaskbrowser
On Jun 12, 2009, at 04:06 , Herman Bruyninckx wrote:
> On Fri, 12 Jun 2009, Peter Soetens wrote:
>
>> On Fri, Jun 12, 2009 at 02:13, Stephen Roderick<kiwi [dot] net [..] ...>
>> wrote:
>>> On Jun 11, 2009, at 16:55 , Peter Soetens wrote:
>>>
>>>> On Thu, Jun 11, 2009 at 22:04, Stephen Roderick<kiwi [dot] net [..] ...>
>>>> wrote:
>>>>>
>>>>> On Jun 11, 2009, at 16:01 , Peter Soetens wrote:
>>>>>
>>>>>> On Thu, Jun 11, 2009 at 21:50, S Roderick<kiwi [dot] net [..] ...>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Jun 11, 2009, at 15:46 , Peter Soetens wrote:
>>>>>>>
>>>>>>>> On Thu, Jun 4, 2009 at 21:04, <presseaum [..] ...> wrote:
>>>>>>>>>
>>>>>>>>> Hi, I've found that deployer can load plugin at start up.
>>>>>>>>> All plugins
>>>>>>>>> found in "/usr/lib/rtt/gnulinux/plugins" according to this
>>>>>>>>> [http://orocos.org/node/551 bug/feature].
>>>>>>>>> With corba this issus is properly load according to the
>>>>>>>>> orocos.log
>>>>>>>>> when
>>>>>>>>> deploying with cdeployer:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> When using the ctaskbrowser, the plugin doesn`t seem to be
>>>>>>>>> load.
>>>>>>>>
>>>>>>>> This is because of a flaw in the current architecture. It's the
>>>>>>>> DeploymentComponent that loads the plugins, since the
>>>>>>>> ctaskbrowser
>>>>>>>> application does not have that component, it won't look for
>>>>>>>> plugins.
>>>>>>>>
>>>>>>>> You can solve this by using the deployer-corba-gnulinux
>>>>>>>> application
>>>>>>>> instead of the ctaskbrowser.
>>>>>>>> You can then connect to a remote component typing
>>>>>>>> loadComponent("Name","CORBA") at the TB
>>>>>>>> prompt. Alternatives are loadComponent("IOR:...","IOR") and
>>>>>>>> loadComponent("name.ior","IORFile")
>>>>>>>
>>>>>>> That still won't load the plugins though, will it Peter? Or
>>>>>>> are you
>>>>>>> thinking
>>>>>>> that they'll feed the 2nd deployer a file listing which
>>>>>>> libraries/plugins
>>>>>>> to
>>>>>>> load? Or manually type in loadLibrary() commands?
>>>>>>
>>>>>> The DeploymentComponent in 1.8 does a this->configure() in the
>>>>>> constructor,
>>>>>> and thus searches for plugins. If you wrote your type
>>>>>> registration and
>>>>>> corba
>>>>>> transports as plugins, they should be loaded, shouldn't they? I
>>>>>> need to
>>>>>> look
>>>>>> the exact semantics up again though...
>>>>>
>>>>> Ok, didn't know that. Any way to specify the path for plugins
>>>>> yet?
>>>>
>>>> I had a patch for this, but it seems I didn't merge it. I've
>>>> attached it.
>>>> The idea is that you can specify a site XML file which allows you
>>>> to preload and pre-configure some components. This XML file is by
>>>> default named 'Deployer-site.cpf'. There you can add import
>>>> statements,
>>>> set the ComponentPath etc.
>>>>
>>>> I believe the final consensus was that ComponentPath and
>>>> PluginPath should
>>>> be a) lists of paths that b) can be set by environment variables.
>>>> The
>>>> site-file
>>>> is complementary to this that it allows to set these paths from
>>>> the XML
>>>> file
>>>> instead of the environment.
>>>>
>>>> YYMV(*)
>>>>
>>>> Peter
>>>>
>>>> (*)Your YAGNI May Vary
>>>> <site-file-for-deployer.patch>
>>>
>>> Thinking about it, is there anything stopping us adding this
>>> functionality
>>> as an option directly into "ctaskbrowser"? It would be the only
>>> OCL program
>>> that doesn't benefit from the above, right? This way all OCL
>>> programs would
>>> be consistent.
>>
>> You're right. Just adding a (hidden) DeploymentComponent to
>> ctaskbrowser that does the site-loading
>> would fix this whole issue.
>>
>> This would make ctaskbrowser almost identical to deployer-corba-
>> gnulinux,
>> except that ctaskbrowser connects to a remote component immediately
>> Maybe the best way is to merge ctaskbrowser and deployer-corba-
>> gnulinux
>> into one tool ? What's the typical usage scenario (you'd like) ?
>
> Interesting suggestion...! Can you state explicitly what the real
> semantics
> are of both concepts (the "new" ctaskbrowser and the
> deployer-corba-gnulinux)? If these semantics match, it is indeed a
> good
> opportunity to merge them, into something with an appropriate name,
> and
> with both (or more) "use cases" as configurable properties...
We've talked about this in the past, merging some of these
applications, and IIRC didn't come to a conclusion.
Personally, I seldom use ctaskbrowser. The only time I do is usually
to check network connectivity with a remote deployer. I also never use
cdeployer, and barely remember its differences to the other tools
(it's a corba server thing IIRC).
We really just stick to deployer and deployer-corba.
S
Plugin with ctaskbrowser
On Fri, Jun 12, 2009 at 10:06, Herman
Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>>
>> You're right. Just adding a (hidden) DeploymentComponent to
>> ctaskbrowser that does the site-loading
>> would fix this whole issue.
>>
>> This would make ctaskbrowser almost identical to deployer-corba-gnulinux,
>> except that ctaskbrowser connects to a remote component immediately
>> Maybe the best way is to merge ctaskbrowser and deployer-corba-gnulinux
>> into one tool ? What's the typical usage scenario (you'd like) ?
>
> Interesting suggestion...! Can you state explicitly what the real semantics
> are of both concepts (the "new" ctaskbrowser and the
> deployer-corba-gnulinux)? If these semantics match, it is indeed a good
> opportunity to merge them, into something with an appropriate name, and
> with both (or more) "use cases" as configurable properties...
Old ctaskbrowser = TaskBrowser + Proxy-to-Component-Server
New ctaskbrowser = TaskBrowser + Proxy-to-Component-Server +
CorbaDeploymentComponent + Corba-Component-Server
Where Proxy-to-Component-Server is created with command line IOR info.
Most likely a remote CorbaDeploymentComponent server. The Old style is
a 'classical' client to the cdeployer (see below). The New style would
be both client and server.
deployer-corba = TaskBrowser + CorbaDeploymentComponent + Corba-Component-Server
This application is a networked node with a console front-end as well.
It can connect to remote proxies using the loadComponent trick I
posted earlier, and as such transform itself in New ctaskbrowser.
cdeployer = CorbaDeploymentComponent + Corba-Component-Server
This application is a networked node without any front-end attached
(use ctaskbrowser to attach). It's a classical server.
deployer = TaskBrowser + DeploymentComponent
This application is an 'old style' single process, not networked
Orocos application.
So. The idea of the ctaskbrowser was to have a 'thin' client, no
deployment infrastructure needed.But because the deployer also loads
plugins (ie user data type info), you'll need it anyway at each client
side in order to demarshal and interprete what the remote side is
sending you. So we could a) rip out the plugin loading mechanism of
the DeploymentComponent, put that in RTT[*], such that the
ctaskbrowser can use that or b) add a CorbaDeploymentComponent such
that it has all the bells and whistles a user expects.
I would be guided again by implementation constraints, so I'd rather
have the current CORBA users decide on this.
Peter
[*] We need to do this probably anyway, since the RTT defines a plugin
creation framework, but no way to load them.
Plugin with ctaskbrowser
On Jun 12, 2009, at 04:58 , Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 10:06, Herman
> Bruyninckx<Herman [dot] Bruyninckx [..] ...> wrote:
>>>
>>> You're right. Just adding a (hidden) DeploymentComponent to
>>> ctaskbrowser that does the site-loading
>>> would fix this whole issue.
>>>
>>> This would make ctaskbrowser almost identical to deployer-corba-
>>> gnulinux,
>>> except that ctaskbrowser connects to a remote component immediately
>>> Maybe the best way is to merge ctaskbrowser and deployer-corba-
>>> gnulinux
>>> into one tool ? What's the typical usage scenario (you'd like) ?
>>
>> Interesting suggestion...! Can you state explicitly what the real
>> semantics
>> are of both concepts (the "new" ctaskbrowser and the
>> deployer-corba-gnulinux)? If these semantics match, it is indeed a
>> good
>> opportunity to merge them, into something with an appropriate name,
>> and
>> with both (or more) "use cases" as configurable properties...
>
> Old ctaskbrowser = TaskBrowser + Proxy-to-Component-Server
> New ctaskbrowser = TaskBrowser + Proxy-to-Component-Server +
> CorbaDeploymentComponent + Corba-Component-Server
>
> Where Proxy-to-Component-Server is created with command line IOR info.
> Most likely a remote CorbaDeploymentComponent server. The Old style is
> a 'classical' client to the cdeployer (see below). The New style would
> be both client and server.
>
> deployer-corba = TaskBrowser + CorbaDeploymentComponent + Corba-
> Component-Server
>
> This application is a networked node with a console front-end as well.
> It can connect to remote proxies using the loadComponent trick I
> posted earlier, and as such transform itself in New ctaskbrowser.
>
> cdeployer = CorbaDeploymentComponent + Corba-Component-Server
>
> This application is a networked node without any front-end attached
> (use ctaskbrowser to attach). It's a classical server.
>
> deployer = TaskBrowser + DeploymentComponent
>
> This application is an 'old style' single process, not networked
> Orocos application.
>
> So. The idea of the ctaskbrowser was to have a 'thin' client, no
> deployment infrastructure needed.But because the deployer also loads
> plugins (ie user data type info), you'll need it anyway at each client
> side in order to demarshal and interprete what the remote side is
> sending you. So we could a) rip out the plugin loading mechanism of
> the DeploymentComponent, put that in RTT[*], such that the
> ctaskbrowser can use that or b) add a CorbaDeploymentComponent such
> that it has all the bells and whistles a user expects.
So the use case scenarios might be (with arbitrary option names)?
# bring up console
new-taskbrowser
# connect to remote deployer (ala current ctaskbrowser)
new-taskbrowser -connect-to remote-deployer-name
# start deployment and provide console (ala deployer),
new-taskbrowser -deploy path/to/deploymentfile.xml
# start deployment on network and provide console (ala deployer-corba)
new-taskbrowser -corba -deploy path/to/deploymentfile.xml
# start deployment on network without console (ala cdeployer)
new-taskbrowser -no-console -corba -deploy path/to/deploymentfile.xml
> I would be guided again by implementation constraints, so I'd rather
> have the current CORBA users decide on this.
>
> Peter
>
> [*] We need to do this probably anyway, since the RTT defines a plugin
> creation framework, but no way to load them.
Agreed, but is the only benefit of the above proposed changes that the
current ctaskbrowswer can't load plugins? If so, why not just push the
plugin loading into RTT as you suggest, and then refactor that
forwards into the existing four programs: ctaskbrowser, deployer,
deployer-corba, cdeployer. Three of the four programs currently aren't
broken ...
Stephen
Plugin with ctaskbrowser
On Fri, Jun 12, 2009 at 13:38, S Roderick<kiwi [dot] net [..] ...> wrote:
> So the use case scenarios might be (with arbitrary option names)?
>
> # bring up console
> new-taskbrowser
>
> # connect to remote deployer (ala current ctaskbrowser)
> new-taskbrowser -connect-to remote-deployer-name
>
> # start deployment and provide console (ala deployer),
> new-taskbrowser -deploy path/to/deploymentfile.xml
>
> # start deployment on network and provide console (ala deployer-corba)
> new-taskbrowser -corba -deploy path/to/deploymentfile.xml
>
> # start deployment on network without console (ala cdeployer)
> new-taskbrowser -no-console -corba -deploy path/to/deploymentfile.xml
As a user, I have rather a different tool name than a different
option. I'm terrible at remembering options.
>
>
>> I would be guided again by implementation constraints, so I'd rather
>> have the current CORBA users decide on this.
>>
>> Peter
>>
>> [*] We need to do this probably anyway, since the RTT defines a plugin
>> creation framework, but no way to load them.
>
> Agreed, but is the only benefit of the above proposed changes that the
> current ctaskbrowswer can't load plugins? If so, why not just push the
> plugin loading into RTT as you suggest, and then refactor that forwards into
> the existing four programs: ctaskbrowser, deployer, deployer-corba,
> cdeployer. Three of the four programs currently aren't broken ...
That will take longer than just adding a deployer to ctaskbrowser.
Just adding a hidden DeploymentComponent in the ctaskbrowser
executable would solve the whole issue for ctaskbrowser, without the
user noticing the change (except for the plugins now working, and
that we added a dependency on the DeploymentComponent).
Also, there will be a point in time that backporting features to the 1.x
branch will get harder and harder. So I'm tempted to use a quick fix
for a 1.x problem than go through the whole chain for the sake of
clean design. It will be clean in 2.0.
So:
For 1.x: keeping the programs, and add hidden DeploymentComponent
For 2.x: Move plugin loading to RTT + think a bit more on how to define
browsers and deployers in OCL
?
Peter
Plugin with ctaskbrowser
Hi, our team use a lot the ctaskbrowser to control and monitor many
components at same time.
The proposition of many options provide a flexible solution but isn't really
friendly to use.
For 1.x: keeping the programs, and add hidden DeploymentComponent will be
fine.
For 2.X: Users doesn't want to remember to many options. If all is merge in
one tool, you better document it a lot because user will not user it because
of the complexity. User may write a script of alias that create the two
application that you will toke a lot of work to merge. At a programming
point of view, it could be great to use the almost the same code to offer a
complete solution and easy to maintain.
Thanks for the answer!
-----Original Message-----
From: orocos-users-bounces [..] ...
[mailto:orocos-users-bounces [..] ...] On Behalf Of Peter
Soetens
Sent: 12 juin 2009 08:07
To: S Roderick
Cc: Herman Bruyninckx; orocos-users [..] ...
Subject: Re: [Orocos-users] Plugin with ctaskbrowser
On Fri, Jun 12, 2009 at 13:38, S Roderick<kiwi [dot] net [..] ...> wrote:
> So the use case scenarios might be (with arbitrary option names)?
>
> # bring up console
> new-taskbrowser
>
> # connect to remote deployer (ala current ctaskbrowser)
> new-taskbrowser -connect-to remote-deployer-name
>
> # start deployment and provide console (ala deployer),
> new-taskbrowser -deploy path/to/deploymentfile.xml
>
> # start deployment on network and provide console (ala deployer-corba)
> new-taskbrowser -corba -deploy path/to/deploymentfile.xml
>
> # start deployment on network without console (ala cdeployer)
> new-taskbrowser -no-console -corba -deploy path/to/deploymentfile.xml
As a user, I have rather a different tool name than a different
option. I'm terrible at remembering options.
>
>
>> I would be guided again by implementation constraints, so I'd rather
>> have the current CORBA users decide on this.
>>
>> Peter
>>
>> [*] We need to do this probably anyway, since the RTT defines a plugin
>> creation framework, but no way to load them.
>
> Agreed, but is the only benefit of the above proposed changes that the
> current ctaskbrowswer can't load plugins? If so, why not just push the
> plugin loading into RTT as you suggest, and then refactor that forwards
into
> the existing four programs: ctaskbrowser, deployer, deployer-corba,
> cdeployer. Three of the four programs currently aren't broken ...
That will take longer than just adding a deployer to ctaskbrowser.
Just adding a hidden DeploymentComponent in the ctaskbrowser
executable would solve the whole issue for ctaskbrowser, without the
user noticing the change (except for the plugins now working, and
that we added a dependency on the DeploymentComponent).
Also, there will be a point in time that backporting features to the 1.x
branch will get harder and harder. So I'm tempted to use a quick fix
for a 1.x problem than go through the whole chain for the sake of
clean design. It will be clean in 2.0.
So:
For 1.x: keeping the programs, and add hidden DeploymentComponent
For 2.x: Move plugin loading to RTT + think a bit more on how to define
browsers and deployers in OCL
?
Peter
Plugin with ctaskbrowser
On Jun 12, 2009, at 08:07 , Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 13:38, S Roderick<kiwi [dot] net [..] ...> wrote:
>> So the use case scenarios might be (with arbitrary option names)?
>>
>> # bring up console
>> new-taskbrowser
>>
>> # connect to remote deployer (ala current ctaskbrowser)
>> new-taskbrowser -connect-to remote-deployer-name
>>
>> # start deployment and provide console (ala deployer),
>> new-taskbrowser -deploy path/to/deploymentfile.xml
>>
>> # start deployment on network and provide console (ala deployer-
>> corba)
>> new-taskbrowser -corba -deploy path/to/deploymentfile.xml
>>
>> # start deployment on network without console (ala cdeployer)
>> new-taskbrowser -no-console -corba -deploy path/to/deploymentfile.xml
>
> As a user, I have rather a different tool name than a different
> option. I'm terrible at remembering options.
>
>>
>>
>>> I would be guided again by implementation constraints, so I'd rather
>>> have the current CORBA users decide on this.
>>>
>>> Peter
>>>
>>> [*] We need to do this probably anyway, since the RTT defines a
>>> plugin
>>> creation framework, but no way to load them.
>>
>> Agreed, but is the only benefit of the above proposed changes that
>> the
>> current ctaskbrowswer can't load plugins? If so, why not just push
>> the
>> plugin loading into RTT as you suggest, and then refactor that
>> forwards into
>> the existing four programs: ctaskbrowser, deployer, deployer-corba,
>> cdeployer. Three of the four programs currently aren't broken ...
>
> That will take longer than just adding a deployer to ctaskbrowser.
> Just adding a hidden DeploymentComponent in the ctaskbrowser
> executable would solve the whole issue for ctaskbrowser, without the
> user noticing the change (except for the plugins now working, and
> that we added a dependency on the DeploymentComponent).
So not trying to merge ctaskbrowser and deployer for v1.x, just making
ctaskbrowswer plugin aware?
> Also, there will be a point in time that backporting features to the
> 1.x
> branch will get harder and harder. So I'm tempted to use a quick fix
> for a 1.x problem than go through the whole chain for the sake of
> clean design. It will be clean in 2.0.
>
> So:
> For 1.x: keeping the programs, and add hidden DeploymentComponent
> For 2.x: Move plugin loading to RTT + think a bit more on how to
> define
> browsers and deployers in OCL
>
> ?
Works for me. I prefer different tool names also, but I can also write
alises in bash ... :-)
S
Plugin with ctaskbrowser
On Fri, 12 Jun 2009, Peter Soetens wrote:
> On Fri, Jun 12, 2009 at 13:38, S Roderick<kiwi [dot] net [..] ...> wrote:
>> So the use case scenarios might be (with arbitrary option names)?
>>
>> # bring up console
>> new-taskbrowser
>>
>> # connect to remote deployer (ala current ctaskbrowser)
>> new-taskbrowser -connect-to remote-deployer-name
>>
>> # start deployment and provide console (ala deployer),
>> new-taskbrowser -deploy path/to/deploymentfile.xml
>>
>> # start deployment on network and provide console (ala deployer-corba)
>> new-taskbrowser -corba -deploy path/to/deploymentfile.xml
>>
>> # start deployment on network without console (ala cdeployer)
>> new-taskbrowser -no-console -corba -deploy path/to/deploymentfile.xml
>
> As a user, I have rather a different tool name than a different
> option. I'm terrible at remembering options.
>
User configuration is much more easy and flexible than framework object
naming! So, the "option approach" does not prevent you at all of defining
your own user-friendly naming shortcuts :-)
Herman
>>> I would be guided again by implementation constraints, so I'd rather
>>> have the current CORBA users decide on this.
>>>
>>> Peter
>>>
>>> [*] We need to do this probably anyway, since the RTT defines a plugin
>>> creation framework, but no way to load them.
>>
>> Agreed, but is the only benefit of the above proposed changes that the
>> current ctaskbrowswer can't load plugins? If so, why not just push the
>> plugin loading into RTT as you suggest, and then refactor that forwards into
>> the existing four programs: ctaskbrowser, deployer, deployer-corba,
>> cdeployer. Three of the four programs currently aren't broken ...
>
> That will take longer than just adding a deployer to ctaskbrowser.
> Just adding a hidden DeploymentComponent in the ctaskbrowser
> executable would solve the whole issue for ctaskbrowser, without the
> user noticing the change (except for the plugins now working, and
> that we added a dependency on the DeploymentComponent).
>
> Also, there will be a point in time that backporting features to the 1.x
> branch will get harder and harder. So I'm tempted to use a quick fix
> for a 1.x problem than go through the whole chain for the sake of
> clean design. It will be clean in 2.0.
>
> So:
> For 1.x: keeping the programs, and add hidden DeploymentComponent
> For 2.x: Move plugin loading to RTT + think a bit more on how to define
> browsers and deployers in OCL
>
> ?
>
> Peter
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480
Coordinator of EURON (European Robotics Research Network)
<http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Plugin with ctaskbrowser
Hi, I've found that deployer can load plugin at start up. All plugins found in "/usr/lib/rtt/gnulinux/plugins" according to this bug/feature <http://orocos.org/node/551> (http://orocos.org/node/551). With corba this issus is properly load according to the orocos.log when deploying with cdeployer:
0.002 [ Info ][cdeployer-gnulinux::main()] Loading plugins from /usr/lib/rtt/gnulinux/plugins
0.002 [ Debug ][DeploymentComponent::import] Importing /usr/lib/rtt/gnulinux/plugins
0.002 [ Debug ][DeploymentComponent::import] Scanning /usr/lib/rtt/gnulinux/plugins/libCablesToolKit.so
0.002 [ Debug ][DeploymentComponent::import] Accepting libCablesToolKit.so
When using the ctaskbrowser, the plugin doesn`t seem to be load. In this case, the plugin create new type to be used with the templated Property class. The ctaskbrowser load sucessfully but when you list a componant with plugin type, you get the following message:
237.778 [ ERROR ][TypeInfoName] Looking up Property CornerCubeCan not build Property of unknown_t.
where CornerCubeCan is defined in our toolkit.
This work fine with deployer.
Can someone help me?
Thanks a lot!
PS. Sorry for the double post on forum, first time, I used directly the forum but I didn't receive any comments.
Plugin with ctaskbrowser
Hi, I've found that deployer can load plugin at start up. All plugins found in "/usr/lib/rtt/gnulinux/plugins" according to this [http://orocos.org/node/551 bug/feature].
With corba this issus is properly load according to the orocos.log when deploying with cdeployer:
When using the ctaskbrowser, the plugin doesn`t seem to be load.
In this case, the plugin create new type to be used with the templated Property class. The ctaskbrowser load sucessfully but when you list a componant with plugin type, you get the following message:
where CornerCubeCan is defined in our toolkit
Can someone help me?
Thanks a lot!