For more infomation about this bug, visit

--- Comment #7 from S Roderick <kiwi [dot] net [..] ...> 2008-05-22 22:42:07 ---
(In reply to comment #6)
> We certainly need to get rid of the segfault 'behavior' asap. I've done the
> necessary changes in RTT to avoid null pointer returns when a type is unknown.

Is this checked into trunk then?

> Next a simple 'import("/path/to/kdl-plugin")' should make KDL types available.

The Toolkit::Import() with the KDL plugin works fine, but it won't work with
the Corba plugin. That plugin appears to only support dynamic loading - the
Corba loadRttPlugin() just registers transport with Corba, it doesn't actually
"import" the toolkit. I had to import KDL and use dynamic plugin loading to get
KDL Corba. This looks like it might be an easy fix by just adding the
Toolkit::Import() line into the corba logRttPlugig() function, but does this
have any side effects?

> Note that we have two libraries: one which is the KDL type plugin and one which
> is the KDL corba plugin... Both are required in your case. I'm still not
> completely satisfied with the current way of loading plugins. Any ideas are
> still welcome.

Re loading plugins, a couple of ideas for just the taskbrowser case 1) have
command line arg's specify plugins to load (eg ctaskbrowser --load
/path/to/kdlplugin ...) and/or 2) take some of the deployment functionality and
drop it into the taskbrowser so that it can use a (simplified) XML file to
"import" libraries/plugins.

For more infomation about this bug, visit

Peter Soetens
<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |peter [dot] soetens [..] ...

--- Comment #6 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-05-22 22:14:55 ---
We certainly need to get rid of the segfault 'behavior' asap. I've done the
necessary changes in RTT to avoid null pointer returns when a type is unknown.
Next a simple 'import("/path/to/kdl-plugin")' should make KDL types available.
Note that we have two libraries: one which is the KDL type plugin and one which
is the KDL corba plugin... Both are required in your case. I'm still not
completely satisfied with the current way of loading plugins. Any ideas are
still welcome.

For more infomation about this bug, visit

--- Comment #5 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 16:33:58 ---
Adding run-time dynamic load of the KDL Corba plugin (lifted code from
DeploymentComponent.cpp) as well as the compile-time import of KDL fixes this
problem.

So the question is am I doing this completely wrong, or if not, how do we
structure proper modifications to ctaskbrowser to allow the user to load
plugins, etc, at runtime??

Cheers
S

For more infomation about this bug, visit

--- Comment #4 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 15:50:22 ---
Created an attachment (id=298)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=298)
deployer-corba log from ctaskbrowser with explicit KDL toolkit import

For more infomation about this bug, visit

--- Comment #3 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 15:49:58 ---
Created an attachment (id=297)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=297)
Log from ctaskbrowser with explicit KDL toolkit import

For more infomation about this bug, visit

--- Comment #2 from S Roderick <kiwi [dot] net [..] ...> 2008-05-21 15:49:26 ---
Explicitly added import of KDL toolkit into ctaskbrowser.cpp, and now we get a
different seg fault. :-(

"Corba: Do not know how to narrow to frame"

Logs attached.
S