Preparing rc1

Submitted by peter on Mon, 2010-08-02 09:16

RTT-dev

We've decided during the dev meeting that some changes need to be done before
we release. These are (from the wiki):

a Code size/compilation time issue
b Tool + cmake macros to create new component projects
c typegen tool to generate type kits
d gitorious migration of all orocos projects, including code generation tools
e OCL cleanup and migration to new cmake macros
f Some important renamings.
g Supporting enums.
h Cleanup addEventPort and updateHook(vector<PortInterface>)
i race in port disconnection + read/write port
j. website revamping

I'll tackle them in that order.

a. The compilation time + memory use for the RTT is mainly due to the
'TemplateTypeInfo' class that instantiates an input and output port for each
type it declares. Each port declares 2 RTT::Operations, and it's that which
takes up a lot of memory (blame boost::fusion) and code size eventually.

Solutions:
* create 'addSynchronousOperation()' for operations that can not be sent.
Register the port's operations with this function instead of addOperation().
This greatly reduces code size and compilation times and is the quickest fix.
It is likely that we will add this now and do the points below in later
releases.

* Move the operation construction code of ports to the type TypeInfo
interface. Then ports would only have scripting operations when the TypeInfo
object is known in the type system.We could even have scripting creating these
operations only when it needs them.

* create a 'second class' TypeInfo derivative that can't create ports all
together, ie for data types that are only meant as a member in a struct,
not as a thing on a data port (for example, enums, unsigned shorts etc). The
disadvantage is that if you try to use such a 'second class' type on a port at
run-time, only then the error is detected. Given the current way the type
system is implemented (using full type introspection), I don't find this such a
bad idea. It allows for very minimal typekits (40k for a second class type).
and allows to override it later-on in case another part of the app requires it
as a full type.

* Do even more cleanups in the operation code to avoid combinatorial
explosions. That's an opportunity I spotted at the end of the -dev workshop.
We will win some again, but clearly not cut the time in half or better. I have
a partial patch on this, not sure if it will make it in to final due to time
limits.

b. We need a tool to quickly create a new component. The required cmake macros
will be maintained by the orocos-toolchain project and will be included by the
component such that they are maintained at a central place. Adolfo is working
on this.

c. Sylvain is working on typegen, a stand-alone version of orogen that only
generates typekits from a given header. He's also working on a gcc-xml version
that won't need modifications of user headers.

d. We're migrating to gitorious to form the orocos-toolchain project. A
typical user will download the full project. It will contain rtt, ocl, orogen
and all their dependencies (typelib, log4cpp,...). We need to coordinate with
all Orocos maintainers to see what is part of the toolchain.

e. Once point b is ready, OCL will be migrated to these macros.

f. We will rename 'Method' to 'OperationCaller'; 'ServiceProvider' to
'Service'. Method didn't explain it and was probably too confusing to
newcomers and even for 1.x users. Also, the 'RTT::interface' namespace will go
away and classes will move in the main RTT namespace. All occurences of
'*Repository' will be renamed to '*Interface' (like DataFlowInterface).
AttributeRepository will be renamed to ConfigurationInterface. So you'll have:
Service inherits from ConfigurationInterface, OperationInterface and
DataFlowInterface. Oh yes, DataFlowInterface moves from TaskContext to
Service. As a consequence, TaskContext becomes only an execution container
with some states and a default Service.
The RTT::base namespace will be thinned. Most will move to internal, except
some key base classes users will be exposed to. These are: ActivityInterface,
AttributeBase, (Input/Ouput)PortInterface, OperationBase, PropertyBase,
RunnableInterface, ExecutableInterface, DisposableInterface, TaskCore.

g. We've been working on supporting enums such that they can be marshalled to
XML as ints or as strings (EnumTypeInfo). I have a partial patch for this
which needs more testing. typegen is the primary user of this functionality.

h. The updateHook(vector<PortInterface>) function will be removed. It's no
longer necessary since you can query the ports yourself. It greatly simplifies
addEventPort and some management code in TaskContext.

i. There is a race in disconnection + read/write of channel elements. Because
they use boost::intrusive, their destruction is not thread-safe, even if the
ref-counting is. The solution here is to use a lock to guard a read or write
such that no destruction is done when that lock is held. Sylvain is looking at
this.

j. We discussed about revamping documentation and website. I don't have time
for the website, although we had some great ideas. Anyone having some drupal
knowledge or spare time, tell us, we'll send you some whiteboard mockups of
how it should look like and we can setup a test website (copy of existing)
where you can play with it.

For now, my main repository is still github. There are some uptime issues with
gitorious. Hopefully these will be resolved quicly and I'll start pushing to
my personal gitorious repository. From there, we can merge to the mainline.

Peter