The Orocos Project - Guidelines

(Yet another) guide to cross compiling the Orocos Toolchain

sspr — Mon, 27 May 2013 22:02:16 +0000

Sagar Behere has written down a nice blog post on a new way of cross compiling the Orocos Toolchain. See his announcement below:

Quote:

For what it's worth, here is another howto

http://techblog.sagar.se/blog/2013/05/16/yet-another-guide-to-cross-compiling-the-orocos-toolchain/

This method is quite painless, because there is no need to cross-compile the various supporting stuff like boost, libxml2, omniorb etc. Instead, we use xapt.

The howto is attached in markdown format, if anyone wants to put it on the orocos wiki.

Just my way of saying thanks for the good help I receive here :)

/Sagar

[PATCH] Improve naxes documentation

sspr — Wed, 13 Feb 2008 13:50:02 +0000

I've skimmed through the orocos-naxes.xml document and found
that the file has invalid XML.

Some rules to respect:

* Text should always be enclosed by a
element
* The id field (id="xyz") should not contain spaces
* Do not use , ,... as these do not allow composition of
documents or easy moving of sections without renaming. Use

instead.
* Use instead of when writing class names.

If you're using emacs, you can use the 'nxml' and 'relax-ng' (rng) schemes for
editing and debugging XML files.

Commit messages guidelines & Bugzilla

sspr — Thu, 24 Jan 2008 09:25:03 +0000

This is for all RTT,KDL,BFL,OCL folks.
I'm noticing that the commit messages related to the bug tracking are quite
unreadable. For example: "Makes the CaptureCamera component work again with
RTT 1.4, applying patch 210 for bug 492".

That should be: "Fixes bug #492: Update CameraComponents to meet Component
Guidelines (attachment #210). Makes the CaptureCamera component work again
with RTT 1.4."

The rationale is this:
* Always start the message with the bug number info in front. The bug number
is formatted as "bug #%d", where %d is your number.

[OCL] Component guidelines

sspr — Thu, 10 Jan 2008 15:05:01 +0000

In response to Klaas' mail, I'd like to set the standard for acceptable OCL
C++ components.

There are clearly two groups of components: hardware independent and hardware
dependent components. I believe both groups should be represented in OCL.

The question raises what, for example, a 'demotool' hardware component is of
use to the rest of the world. This and other components control custom
hardware and could only serve as an example. However, examples should be
clear, not confusing and testable on any platform. That just excludes about

Improving orocos code quality

klaas — Thu, 03 Jan 2008 16:25:03 +0000

[This email applies to all orocos subprojects]

I want to start a discussion about ways of improving the quality of
the "official" [*] orocos source code.

Please provide feedback on the following first draft of suggestions,
which should be regarded as complementary with respect to the
guidelines you can already find at :

1/ The first basic idea is that each subproject has
- a single release manager RM (who makes final decisions)
- a limited list of people having commit-access to that subproject