Hi Diego,

On Thu, Jun 26, 2014 at 6:36 PM, <dgerb [..] ...> wrote:

> Hi,
> I am using orocos toolchain 2.6 under gnulinux. I am using also the
> import
> function from deployer to import an installed component package.
> The package is correctly imported and the relative component loaded (by
> loadComponent).
> Then, if I modify, re-build and install the component without restart
> the
> deployer, a new import simply has no effect: the old component is loaded.
>

What you are trying here is highly experimental and AFAIK untested. I don't
even know if it is really supported.

Can you run your deployment with ORO_LOGLEVEL set to Debug (6), and post
the output, maybe we can see some stuff in the Debug output that would
clarify what's going on.

Have you tried the reloadLibrary function of the deployer (I'm looking at
toolchain-2.7/master)?:

reloadLibrary( string const& FilePath ) : bool
Reload a new component library into memory.
FilePath : The absolute file name of the to be reloaded library.
Warning: this is a low-level function only to be used during
development/testing.

Ruben

I need to quit and restart the deployer to have the modifications be
> effective.
> This problem seems to me related to bug:
>
> http://www.orocos.org/forum/rtt/rtt-dev/bug-1001-new-deployer-claims-ove...
> relative to toolchain 2.5.
> However, file ComponentLoader.cpp file is correct in my case.
>
> Thanks in advance.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Hi MDC,

On Wed, Jul 17, 2013 at 3:59 PM, <mirkodaniele [dot] comparetti [..] ...> wrote:

> Dear all,
> I'm facing a problem with the OROCOS operations. Here is what I'm doing in
> the component called componentNew
>
>

this->task_name = "componentPeer";
> this->task_ptr = this->getPeer(this->task_name);
>
> if (!this->task_ptr) {
>         return false;
> }
> if (this->task_ptr->isActive()) {
>         this->task_oper = this->task_ptr->getOperation("operationName");
> }
> 

std::string task_name;
> TaskContext* task_ptr;
> RTT::OperationCaller task_oper;
> 

(Taken from the manual at the link that you provided): Section 3.4.1
...
Next we move on to methods with arguments and return values by using the
getName and changeParameter operations:

// hold return value of changeParameter:
double oldvalue;
OperationCaller<double(double)> mychange =
a_task_ptr->getOperation("changeParameter"); // double
changeParameter(double)

...

The code compiles but I verified that the task_ptr is NULL. I followed the
> instruction in from
> [
> http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-compo...
> 3.4.1], but it seems that I'm I suppose that I'm trying to get the
> reference
> of the peer in the wrong way. In my xml schema I'm importing and loading
> the
> component componentPeer and the current component
> componentNew
>
> Do I need to add something in the xml deployment schema? Or is there any
> other solution?
>
>
You have to make sure both components are connected as explained in
http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/ocl/v2.x/doc-xml/orocos-deployment.html#idp33098864(Section
2.4.6)

2.4.6. Setting up peer-to-peer relations

The last section of the Reporter component lists its peers.

<struct name="Peers" type="PropertyBag">
<simple type="string"><value>Controller<value><simple>
<struct>

The Reporter has one peer, the Controller, which allows the Reporter
component to scan and use the interface of the Controller component. For
example, it will discover which ports Controller exposes and be able to
create connections to them, without the need of a supervisor to do so.

The Controller component has the Plant as peer, which means it can query
and control it. For example, use its services, start and stop it etc.

> Thank you for your help,
>
>
Ruben

> Best regards,
>
> Mirko
>
>

On Oct 15, 2013, at 12:09 , Andrew Wagner <andrew [dot] wagner [..] ...> wrote:

> Hello Orocos Folks,
>
> We are compiling our components with clang++. In the components for
> which we (Milan) have written nice typekits, we are getting the
> following compiler warning:
>
> 14) [6.395s] components/main/LEDTracker/types: clang++ -Wall -O3
> -march=native -mtune=native -fPIC -fno-strict-l1
> -I../../../../components/carousel2 `pkg-config --cflags
> orocos-rtt-gnulinux orocos-ocl-gnulinux` -c LEDTracke
> LEDTrackerTypekit.cpp:25:1: warning: 'getRTTPluginName' has C-linkage
> specified, but returns user-defined type '
> ORO_TYPEKIT_PLUGIN( LEDTrackerTypekit )
> ^
> /home/awagner/planepower/extern/orocos/install/include/rtt/types/TypekitPlugin.hpp:138:32:
> note: expanded from m
> RTT_EXPORT std::string getRTTPluginName(); \
> ^
> LEDTrackerTypekit.cpp:25:1: warning: 'getRTTTargetName' has C-linkage
> specified, but returns user-defined type '
> /home/awagner/planepower/extern/orocos/install/include/rtt/types/TypekitPlugin.hpp:143:32:
> note: expanded from m
> RTT_EXPORT std::string getRTTTargetName(); \
>
> This error comes from this macro definition in Orocos:
>
> #define ORO_TYPEKIT_PLUGIN ( TYPEKIT
> )
>
> namespace RTT { class TaskContext; } \
> extern "C" { \
> RTT_EXPORT bool loadRTTPlugin(RTT::TaskContext* tc); \
> bool loadRTTPlugin(RTT::TaskContext* tc) { \
> if (tc == 0) { \
> RTT::types::TypekitRepository::Import( new TYPEKIT() ); \
> return true; \
> } \
> return false; \
> } \
> RTT_EXPORT std::string getRTTPluginName(); \
> std::string getRTTPluginName() { \
> TYPEKIT tk; \
> return tk.getName(); \
> } \
> RTT_EXPORT std::string getRTTTargetName(); \
> std::string getRTTTargetName() { \
> return OROCOS_TARGET_NAME; \
> } \
> }
>
> As you can see, several functions with C linkage are indeed returning
> C++ strings. I suppose this is benign? I assume this stuff is never
> compiled in a C compiler, and the extern "C" is just to turn off name
> mangling for some reason, but perhaps there's another compiler
> directive that can achieve the same thing without generating warnings?
>
> Cheers,
> Andrew