On Mon, Aug 3, 2009 at 1:48 PM,
b [dot] j [dot] burgers [..] ...<b [dot] j [dot] burgers [..] ...> wrote:
> Thanks for the quick response.
> I thought this wasn't the approprate place for these kind of questions, so didn't give much info, but seems it is.
>
> OS: 2.6.30-ARCH, arch linux (with KDEmod)
> GCC: 4.4.0 20090630 (prerelease)
> cmake version: 2.6-patch 4
>
> from /home/Bas/Downloads/orocos-rtt-1.8.4/build/ I run
> ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4
> >From the output (at the bottum of the post) everything seems fine, except that the Xercers headers are not found.

The Xerces headers are not a problem. The are not really needed.

> When running "make" I get this output:
>    [ 68%] Building CXX object src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o
>    /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp: In function 'std::string float_to_string(float)':
>    /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp:183: error: 'snprintf' was not declared in this scope
>    make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o] Error 1
>    make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
>    make: *** [all] Error 2

This is strange, normally snprintf is declared in cstdio, can you make
sure that it is? Maybe it is an gcc 4.4 compiler issue (i currently
use gcc 4.3 and do not have the problem you are having)

> Now using "make install" gives the same errors.

That normal, make install tries to do make again since make failed.

> In case it is important that the Xercers headers are found.
> My .profile:
>    # .bash_profile
>    #needed for orocos:
>    export LD_LIBRARY_PATH=$ACE_ROOT/lib:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/lib:$LD_LIBRARY_PATH
>    ACE_ROOT=/home/bin/ACE_wrappers ; export ACE_ROOT
>    TOA_ROOT=$ACE_ROOT/TAO; export TOA_ROOT
>    JAVA_HOME=/opt/java/bin
>    PATH=$PATH:$JAVA_HOME:/home/bin:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/bin
>    export JAVA_HOME
>    export PATH
>
> Output of ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4:
>    Orocos configure script.  WARNING: ONLY WORKS FOR GNULINUX INSTALLATIONS
>    Invoking: '  /usr/bin/cmake ..  -DCMAKE_INSTALL_PREFIX=/home/bin/orocos/orocos-rtt-1.8.4'
>    -- The C compiler identification is GNU
>    -- The CXX compiler identification is GNU
>    -- Check for working C compiler: /usr/bin/gcc
>    -- Check for working C compiler: /usr/bin/gcc -- works
>    -- Detecting C compiler ABI info
>    -- Detecting C compiler ABI info - done
>    -- Check for working CXX compiler: /usr/bin/c++
>    -- Check for working CXX compiler: /usr/bin/c++ -- works
>    -- Detecting CXX compiler ABI info
>    -- Detecting CXX compiler ABI info - done
>    Orocos RTT version  (1.8.4)
>    Setting build type to 'RTT'
>    -- Build type set to 'RTT' by user.
>    -- Looking for Boost/C++ headers --
>    -- Looking for Boost headers - found
>    -- Looking for Xerces - headers not found
>    CMAKE_VERSION: 2.6.4
>    -- Detected gcc4: 4.4.0
>
>    -- Found Doxygen: /usr/bin/doxygen
>    -- Found Doxygen -- API documentation can be built
>    Disabling packaging for version 2.6
>    -- Configuring done
>    -- Generating done
>    -- Build files have been written to: /home/Bas/Downloads/orocos-rtt-1.8.4/build
>
>    OK: configure done. Now issue 'make'.
>
This looks ok.

Ruben

On Aug 3, 2009, at 07:48 , b [dot] j [dot] burgers [..] ... wrote:

> Thanks for the quick response.
> I thought this wasn't the approprate place for these kind of
> questions, so didn't give much info, but seems it is.
>
> OS: 2.6.30-ARCH, arch linux (with KDEmod)
> GCC: 4.4.0 20090630 (prerelease)
> cmake version: 2.6-patch 4
>
> from /home/Bas/Downloads/orocos-rtt-1.8.4/build/ I run
> ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-
> rtt-1.8.4
>> From the output (at the bottum of the post) everything seems fine,
>> except that the Xercers headers are not found.
> When running "make" I get this output:
> [ 68%] Building CXX object src/CMakeFiles/orocos-rtt-
> dynamic_gnulinux.dir/os/rtconversions.o
> /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp: In
> function 'std::string float_to_string(float)':
> /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp:
> 183: error: 'snprintf' was not declared in this scope
> make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/
> rtconversions.o] Error 1
> make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all]
> Error 2
> make: *** [all] Error 2
> Now using "make install" gives the same errors.

Looks like you need to add "#include <stdio.h>" to the file /path/to/
rtt/src/os/rtconversions.cpp. The various GCC versions require
different header files, and we reguarly end up tweaking files for
these sort of issues.

HTH
Stephen

It is still not clear to me whether it makes sense to report my experiences
as a new orocos user, and if so where.

I had a look at the wiki. Here are my observations:

1. The link to the wiki is hard to find; I don't think the average newbie
will click it. The link "what is orocos?" looks much more attractive.

2. On the wiki main page, there are five links, all of which are either
cryptic (what is KDL, OCL or RTT?) or discouraging (wiki for site admins)
for a newbie. I went on and tried some links anyway.

3. KDL is a specific library. Since I am looking for basic information on
how orocos works and what it is useful for, I don't want to dive into a
specific library at this point.

4. OCL is a temporary page with hardly any useful information.

5. RTT leads to a page that does not even explain what RTT is.

It's not clear to me at this point what part of the wiki is supposed to be
useful to a newcomer.

What I am really looking for first is some basic information:

1. What is OROCOS?

It seems to be multiple things:
- a framework providing a mechanism to split a real-time control application
into more or less independent components
- some libraries of components using this mechanism

To get started, I want to first understand the mechanism.

The "What is OROCOS" page mentions 4 C++ libraries. It is not clear which
of these implements the mechanism. I guess its RTT?

2. How is OROCOS different from other ways to implement such applications?
Why or in what circumstances is it better? In other words, information
that allows me to judge early if OROCOS could be useful for my current
project.

3. Installation + a simple hello world so that I can understand the basic
mechanism of building something with OROCOS.

I know that someone installed OROCOS on my computer, but I don't know
where, or what to look for.

Other people will need more detailed instructions on how to download and
install it, on what platforms it works, ...

I am looking for -L -l and -I options needed to compile a simple
orocos-hello-world.

Plus maybe information on what kind of build environment I need to setup.
Cmake? Eclipse?

4. Some kind of tutorial.

A more experienced colleague pointed my to a kind of tutorial downloadable
from the website, explaining that it is quite hard to find. If it is hard
to find for an experienced user, how can a new user find it?

It's called rtt-exercises-1.8.1 and I am starting to read the README now.

Regards,
Johan

On Wed, Jul 22, 2009 at 12:30 PM, Peter Soetens <peter [..] ...>wrote:

> On Fri, Jul 17, 2009 at 17:56, S Roderick<kiwi [dot] net [..] ...> wrote:
> > On Jul 17, 2009, at 11:27 , Peter Soetens wrote:
> >
> >> On Fri, Jul 17, 2009 at 17:14, Johan Cockx<johan [..] ...> wrote:
> >>>
> >>> I am trying to get started using OROCOS.
> >>>
> >>> I already found out that it is quite hard to find the right
> documentation
> >>> and the best way to get started just by reading the orocos webpages.
> >>>
> >>> Would it make sense to document the problems I encounter, so that the
> >>> learning curve for new users could be made a little less steep? I
> mean,
> >>> if
> >>> I spend the effort to document this, will anyone use this information
> to
> >>> actually improve the documentation and/or add information to the
> website?
> >>>
> >>
> >> The idea is that 1. the wiki on the website should be the primary
> >> resource for getting started and are maintained by users and
> >> developers, the manuals (written in docbook-xml) are for reference and
> >> written by developers. Feel free to create an account and play around
> >> with the wiki!
> >
> > Ok, then how do we structure the Wiki
> > help/tutorials/examples/getting-started section? This same problem keeps
> > cropping up and we've made very little progress on it.
> >
> > As a starting point (revived from previous discussions)
> >
> > 1. Get the FAQ out of XML and into the wiki so that it can be
> > modified/updated by all. Peter you hold the copyright, any problem with
> > having this move done for you?
>
> I have no problem with any manual. The advantage of the docbook FAQ is
> that it contained tags for question/answer pairs. Copying a docbook
> document to mediawiki is time consuming.
> Maybe this can help
>
> http://wiki.blender.org/index.php/Meta:Tools/Wiki_conversions/DocBook_to...
> ?
>
> >
> > 2. Create a "getting started" page with pointers to downloading,
> installing,
> > and building basic hello world app (Peter's recent "quicky" would be
> great
> > for this). There are plenty of sites out there with examples of this
> > structure - OpenCV, Boost, etc. The installation help in the online
> manuals
> > is woefully out of date, and doesn't include any of the new operating
> system
> > we now support, nor new package managers. Again, I suggest copy the
> existing
> > XML code to wiki pages and start updating that.
> >
> > 3. Tutorials/examples/help. This is hard to structure, but I am *really*
> > impressed with the Qt tutorials and examples. They are a fabulous way to
> > walk beginners through their code. I would recommend copying their
> approach
> > - focussed examples containing code and explanations, as well as the
> > complete source files (and add in whatever CMake files are required to
> > build). They also distinguish tutorials from examples. A tutorial walks
> you
> > through building a complete application, in small, easily digestible
> steps.
> > An example shows you how to do one focussed thing. Orocos needs both.
> >
> > 4. Personally, I find the docbook-xml approach useless as a community
> > documentation effort. It is simply too hard to mod the file's, check they
> > build, generate a patch, send the patch, wait for the patch to be
> committed,
> > wait for the changed doc's to be built, and then finally uploaded to the
> > website. This takes way too long, compared to simply updating a wiki. Now
> > when it comes to the detailed documentation, like the "Component Builders
> > Manual", an actual document is probably better than lots of wiki pages.
> This
> > criticisim is more levelled at the getting-started/installation/help kind
> of
> > documention.
> >
> > We have some suggestions on the Wiki from previous discucsions.
> >
> > http://orocos.org/wiki/rtt/documentation-suggetsions
> >
> > We, the community, have to move on this. Rather than throwing it back at
> the
> > newbies.
>
> I think you're right on target with all your points. There are however
> also advantages with the docbook approach: It's versioned with the
> sources; when we rename a class/function, we can rename it at once in
> the docs as well; it can be used off-line. The thing I'm most afraid
> of is the aging of wiki pages/online content. A pure mediawiki
> installation is probably better than our drupal hack in terms of tool
> support to do the editing job. I'll try to regain my enthusiasm which
> I had when writing the original documentation and maintaining the
> website. I admire your devotion :-)
>
> Technically speaking and in my opinion, the best we could have is a
> docbook backend (versioned with the sources), a mediawiki frontend and
> a means to transfer the docbook to and from the server for local
> versioning and editing.
>
> Peter
>