[Rock-dev] Feedback from a new user

[Sylvain Joyeux]

First of all, thanks for this very long and productive feedback !!
> * in
> http://gitorious.com/rock/buildconf-all/blobs/raw/master/bootstrap.sh
> the default flavour is "stable", which does not work. Since it does not
> work, the default-flavour should be "master" (which works) to avoid
> confusion.
'master' should be the only option since yesterday. When did you run 
into this problem ?
> * adding a check to the scripts in ./base/scripts/bin/rock-* for the
> parameter "--help" helps. In the moment, the result of "git clone
> --help" is shown, which does not help... Also it may help to escape
> directory's correctly, since this does not work:
> 	cd $ROCK_BASE
> 	rock-create-lib drivers/new_lib
> but this works:
> 	cd $ROCK_BASE/drivers
> 	rock-create-lib new_lib
> some sed-errors are thrown...
Ack.
> * in Rock.make the file Doxygen.In is searched to decide if the doc
> target should be created, but in
> $ROCK_BASE/base/templates/cmake_lib/README the name "doxygen.conf" is
> suggested (so the suggestion is wrong).
Arf. Need to decide on one I guess ;-)
> * after buildconf-all, there are two directory's,
> $ROCK_BASE/template_cmake_lib and $ROCK_BASE/base/templates/cmake_lib,
> pointing to the same gitorius-repo, but having different
> configuration-files
Definitely wrong. Weird that nobody saw it before.
> * when doing "autoproj --help", the printed options are prefixed by a
> double-dash, which is not needed when when giving the options
???? They are indeed needed (just checked to be sure)
> * the ruby-statement "needs_configuration" in an orogen-file changes the
> interface of Task::Task and Task::TaskBase... did cost some time to
> understand this (especially that orogen only changes the template),
> while looking for other problems ;-) Is this necessary?
Yes, it is necessary.

It is also documented there:

   http://rock-robotics.org/orogen/task_states.html

but I guess this is too far down the page. We'll have to think about a 
way to make it clearer.

> * it may help to avoid confusion if a default
> "drivers/orogen/new_lib/scripts/test.rb" is added to the
> template-orogen-project. So a new user is pointed in the correct
> direction, how to execute or use or test a new orocos module in the
> default-way.
That's definitely a nice idea.
> * the new "drivers/orogen/new_lib/new_lib.orogen" file could also
> include default lines for the "doc" statement of each property/port?
Will do.
> * I wanna point out that setting the env-variable "ORBInitRef" like
> suggested here
> http://www.orocos.org/forum/orocos/orocos-users/ctaskcontext-name-could-not-find-corba-naming-service-orogen-example was contra-productive for me. Even when it was empty (but existent in a shell), the message "could not find CORBA Naming Service" appeared after starting the orocos module containing logger and my own module. Sylvain had to unset it explicitly (This may be a bug in omniOrb?)
I don't think it is a bug in omniorb, and I'm really not sure whether 
that was the real problem or not. In any case, when using orocos.rb, you 
should not have any need to fiddle with corba settings.

> * additionally to a working "flavour" mechanism, having the choice to
> checkout and build all repository's with "commits not older than date X"
> or "not older than commit Y" would be nice. So, two people or computers
> could easily be synchronised to have the same sources. I know because of
> the heavy development right now that doesn't make much sense... but
> would be cool anyways
The current solution I was thinking about is to generate an 
overrides.yml that represents the snapshot of an installation. autoproj 
has that feature already, but it really needs testing and it is pretty 
low on my priority list.

> * How can I see what changed in single subrepos before (or after)
> merging them during an "autoproj update"? At least the commit messages
> would be nice, or the amount of changed code. I know I could go manually
> to the subprojects of interest... Don't know how this could be
> accomplished in a more elegant way from $ROCK_BASE?
autoproj status shows what would be changed in every package.
> * Links that where interesting for me (to help point new users in the
> right direction):
> - http://rock-robotics.org/index.html (of course... maybe a little bit
> unstructured... searching would be nice...)
> - http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev (mailing list,
> import all mail in your local E-Mail client)
> - http://gitorious.org/rock
> - http://spacegit.dfki.uni-bremen.de/ (DFKI-intern?)
DFKI Intern
> - http://doudou.github.com/orogen/
Do NOT use this link (how did you get it in the first place ?) It is 
grossly out of date. Uptodate documentation is on rock-robotics.org
> - http://www.omg.org/gettingstarted/corbafaq.htm
If you use orocos.rb, you do not need to know anything about CORBA. Really.
> - http://www.ruby-lang.org/en/ (haven't started yet on this one...)
True. I guess we would need a few links to Ruby ressources from 
rock-robotics.org.

-- 
Sylvain Joyeux
Space&  Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------