Dear Sir,

in the upcoming release, orogen will be able to generate
components that should be loadable by OCL deployer, and all the features
documented on web pages of advanced sytem deployment of dfki/toolchain will be availble ?

Last week you told about a few week for the release of the new version, do you confirm
this timing?

I find orogen an extremely usefull tool in developing and maintaining orocos modules,
and a I am very impatient in using the forseen new features to build complex network of component.

Morovert if orogen will generate loadable components the user could use the orocos OCL deployer approach to mix
orogen generated component with already existing loadable components and this will be (for me ) usefull.

Thank you for your work.

Gianpaolo Rizzi

----Messaggio originale----
Da: sylvain [dot] joyeux [..] ...
Data: 23-nov-2010 6.48 PM
A: "Tinne De Laet"<tinne [dot] delaet [..] ...>
Cc: "Orocos Users"<orocos-users [..] ...>
Ogg: Re: [Orocos-users] some first comments and questions after using orogen to create component code

On 11/23/2010 05:42 PM, Tinne De Laet wrote:
> First of all I think the documentation page about the workflow
> (http://www.orocos.org/dfki/orogen/workflow.html) is missing.
> This way I could not find what command I actually had to use to create
> c++ code from my test.orogen file.
> Since the documentation is not on the wiki, there was also no way I
> could help to complete the documentation.
I have that page ready but I am waiting for other stuff to be ready
before releasing "everything", i.e. orogen for RTT2 + a lot of other
stuff related ot orogen. I just attached the oroGen cheat sheet to this
mail with (hopefully) the missing information.

> The first thing I was puzzled about is about what exactly should be in
> my test.orogen file ... as an example I forgot to define my namespace,
> resulting in an awkward error.
> I think it would definitely help if there is an example file that
> could be downloaded.
orogen create <directory> gives you such a template. You have been hit
by the "missing workflow page" problem.

> Next, I was expecting that the generated component would just inherit
> from TaskContext, but apparently the generated component inherits from
> TaskBase. However, I don't find the TaskBase in the orogen
> API(http://www.orocos.org/dfki/api/orogen/index.html).
> Why is orogen not generating a component that directly inherits from
> TaskContext?
Because orogen does not touch your code. So, if you modify the spec (add
properties, operations, ports, ...), they get added to the Base class.
Base is not in the API documentation as it is part of the code
generation thing, really.

> Another problem I have with the generated code is that the generated
> TaskBase also includes an activity. I don't want to attach an activity
> to my TaskContext at compilation time. I want to attach one at
> configuration time.
Yes, and the taskbase does *not* include an activity. The version you
are using is simply giving an accessor for a "default activity", which
was meant for simplicity reasons. I just removed that accessor by the way.

> Another functionality I was missing at first sight is the decoupling
> between deployement and property initialization.
> It seems that you have to set the value of the properties in your
> deployement blocks with something like: my_task.property = new_value
> In my use cases however I usually have components that read some
> properties from a application-wide property file.
> Is it possible to do something like this in orogen?
The nominal workflow in the orogen-centric toolchain is

* write your tasks. They *are* activity-independent and get compiled
into a task library. With oroGen master, if OCL is installed, that
task library should be loadable in the deployer.
* create deployment processes. The only setup you do there is
assign an activity to a task. Other stuff (setting properties,
connecting ports, ...) is really meant for testing purposes.
* finally, setup and startup your system either with a Ruby script (it
is very simple and requires no knowledge of Ruby, really !) or the
supervision system (more complex, but a lot more powerful).

> Hope my comments and questions help to give a first impression how
> dummy orocos users are working with orogen.
Yes, and this is greatly appreciated. You are being hit by the "not
properly documented problem" that we are fixing at this very moment ;-)