[Rock-dev] buildconf-all / tools-lib

Discussion:

[Rock-dev] buildconf-all / tools-lib_manager

Sylvain Joyeux

2014-09-18 15:21:48 UTC

tools-lib_manager ? I guess that it is your pick for Rock's plugin
system... If you want to continue making decisions this important with
zero *public* discussion [1], you could at refrain from asking me to
be part of it.

Sylvain

[1] Yes, I know, "you discussed it internally".

HEy,
can you fork
git at github.com:jmachowinski/tools-lib_manager.git
and
git at github.com:jmachowinski/buildconf-all.git
into the rock-core organization ?
Thanks
Janosch
--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik
Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: +49 421 178 45-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: jmachowinski at informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

Janosch Machowinski

2014-09-18 15:24:47 UTC

Permalink

Actually you were still in Bremen, when we decided
this. It is the mars plugin lib. But feel free to offer
alternatives.
Greetings
Janosch

Post by Sylvain Joyeux
tools-lib_manager ? I guess that it is your pick for Rock's plugin
system... If you want to continue making decisions this important with
zero *public* discussion [1], you could at refrain from asking me to
be part of it.
Sylvain
[1] Yes, I know, "you discussed it internally".

--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik

Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengesch?ftstelle:
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Tel.: +49 421 178 45-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: jmachowinski at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

Sylvain Joyeux

2014-09-18 15:44:07 UTC

Permalink

On Thu, Sep 18, 2014 at 12:24 PM, Janosch Machowinski

Post by Janosch Machowinski
Actually you were still in Bremen, when we decided
this.

I might have been in Bremen, now it does not mean that I was part of
the discussion. This is why these discussions should be *first* done
on the wiki + ML. Not everyone can be at a meeting (especially not any
non-DFKI person), and for decisions this important, *taking the time
to make the right decision* is critical. This impacts all of rock.
Libraries and framework alike. And if it turns out to be the wrong
decision, switching plugin systems is hell.

Moreover, if something has been discussed more than 6 months ago,
refreshing everyone about it before doing it would be a good idea -
especially if there are no written trace - because (1) we all remember
what we want to remember after 6 months and (2) things might have
changed since then.

I have always been against using anything home-grown, because having
our own in-house plugin system for something as big as rock is just
plain dumb. I also already offered that we should DEFINITELY try to
have a plugin system compatible with ROS'pluginlib. This is hopefully
written somewhere in the framework wiki.

https://github.com/ros/pluginlib/ is almost ros-independent. What's
basically missing is to replace the ROS console messages by
base/console_bridge (a change which could very well be accepted
upstream), get rid of catkin (might be accepted upstream) and have a
different way to find the XML description files than using
ros::package. This is battle-hardened code (having been used for the
last 6 ROS releases) and a *lot* more widespread than lib_manager.

Sylvain

Janosch Machowinski

2014-09-18 18:45:09 UTC

Permalink

Actually, we don't want pluginlib at all.
What we want is :
https://github.com/ros/class_loader

Which actually looks like a fine library.
Janosch

Post by Sylvain Joyeux
On Thu, Sep 18, 2014 at 12:24 PM, Janosch Machowinski

Post by Janosch Machowinski
Actually you were still in Bremen, when we decided
this.

I might have been in Bremen, now it does not mean that I was part of
the discussion. This is why these discussions should be *first* done
on the wiki + ML. Not everyone can be at a meeting (especially not any
non-DFKI person), and for decisions this important, *taking the time
to make the right decision* is critical. This impacts all of rock.
Libraries and framework alike. And if it turns out to be the wrong
decision, switching plugin systems is hell.
Moreover, if something has been discussed more than 6 months ago,
refreshing everyone about it before doing it would be a good idea -
especially if there are no written trace - because (1) we all remember
what we want to remember after 6 months and (2) things might have
changed since then.
I have always been against using anything home-grown, because having
our own in-house plugin system for something as big as rock is just
plain dumb. I also already offered that we should DEFINITELY try to
have a plugin system compatible with ROS'pluginlib. This is hopefully
written somewhere in the framework wiki.
https://github.com/ros/pluginlib/ is almost ros-independent. What's
basically missing is to replace the ROS console messages by
base/console_bridge (a change which could very well be accepted
upstream), get rid of catkin (might be accepted upstream) and have a
different way to find the XML description files than using
ros::package. This is battle-hardened code (having been used for the
last 6 ROS releases) and a *lot* more widespread than lib_manager.
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Martin Zenzes

2014-09-19 07:56:58 UTC

Permalink

Just my two cents: Doing Frameworks means doing things right. Allowing
many persons to profit from the work of smaller subgroup. And this takes
time... Quick-Hacks have no place in a Framework...

Post by Janosch Machowinski
Actually, we don't want pluginlib at all.
https://github.com/ros/class_loader
Which actually looks like a fine library.
Janosch

Post by Sylvain Joyeux
On Thu, Sep 18, 2014 at 12:24 PM, Janosch Machowinski

Post by Janosch Machowinski
Actually you were still in Bremen, when we decided
this.

I might have been in Bremen, now it does not mean that I was part of
the discussion. This is why these discussions should be *first* done
on the wiki + ML. Not everyone can be at a meeting (especially not any
non-DFKI person), and for decisions this important, *taking the time
to make the right decision* is critical. This impacts all of rock.
Libraries and framework alike. And if it turns out to be the wrong
decision, switching plugin systems is hell.
Moreover, if something has been discussed more than 6 months ago,
refreshing everyone about it before doing it would be a good idea -
especially if there are no written trace - because (1) we all remember
what we want to remember after 6 months and (2) things might have
changed since then.
I have always been against using anything home-grown, because having
our own in-house plugin system for something as big as rock is just
plain dumb. I also already offered that we should DEFINITELY try to
have a plugin system compatible with ROS'pluginlib. This is hopefully
written somewhere in the framework wiki.
https://github.com/ros/pluginlib/ is almost ros-independent. What's
basically missing is to replace the ROS console messages by
base/console_bridge (a change which could very well be accepted
upstream), get rid of catkin (might be accepted upstream) and have a
different way to find the XML description files than using
ros::package. This is battle-hardened code (having been used for the
last 6 ROS releases) and a *lot* more widespread than lib_manager.
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
M.Sc. Martin Zenzes
Space Robotics

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

Phone: +49 (0) 421 178 45 - 6658
Fax: +49 (0) 421 178 45 - 4150
E-Mail: martin.zenzes 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
-----------------------------------------------------------------------

Sylvain Joyeux

2014-09-20 20:11:30 UTC

Permalink

Good catch, but we want both. class_loader is the loading mechanism,
pluginlib is the discovery mechanism. You need both to make a plugin
system.

Sylvain