[ros-users] ROS usability -> boost

Mon Feb 24 19:53:32 UTC 2014

Agreed on all points, except that I have header only solutions can be a tricky area. I am seeing a sizeable compile time reduction by moving away from header only approaches. In some cases I see an increase in build time due to use of header only and templates. For example, I changes our Configuration class from using template type accessors to non-templates and received a 1-5% compile time decrease across our repositories. This adds up to man-weeks time savings over the course of the year.

From: ros-users-bounces at lists.ros.org [mailto:ros-users-bounces at lists.ros.org] On Behalf Of William Woodall
Sent: Thursday, February 20, 2014 1:24 PM
To: User discussions
Subject: Re: [ros-users] ROS usability -> boost

I've actually suggested internalizing things in the past, but it should be recognized that it is a trade-off. By internalizing the software you are taking on some support role for that software. Additionally, since you are not forced to update the software by your package manager, you never take on bug fixes or security fixes, which in turn becomes part of the additional maintenance role you take on.

Also if your internalized thing is not header only, it increases the size of your binary and your compile time compared to depending on a shared library.

It also can affect portability. If you depend on boost, then on exotic machines the system provided boost will presumably be patched to work on it, whereas your internalized copy will need those patches applied separately.

I still think internalizing dependencies is a good a idea in some cases, and excluding them where ever possible is better. But it is not a clear advantage in all scenarios.

On Thu, Feb 20, 2014 at 9:03 AM, <rdean at gdrs.com<mailto:rdean at gdrs.com>> wrote:
The advantage of putting a 2 after the name is a new minimum set of requirements, such as Ubuntu 14.0x maybe. Hopefully not 16.0x >.>

Another aspect that I have found is common with my various RCTA collaborators is when selecting a dependency, pulling it into the build tree. Minimize external dependencies of the core. I believe this is what the roscpp authors did with xmlrpc as well, but there seems to be some slipping away from this (see Ryan Gariepy's new thread on usability).

For example, I have an opensource subdirectory which has a version of the json-c library imported into a namespace to remove link time errors with system defaults. My next step, for example, is to extract out boost::chrono from boost itself and build it with the tree. Boost::chrono currently supports nanosecond timer resolution where std::chrono does not. By doing this I can revert back to using the default Ubuntu 12.04 antique version of boost.

A good idea may also be to start a "best practices of software engineering" tutorial or wiki page. There could for example be an article on boost::mpl and its plusses/minuses. From my experience by the time you figure out how to do it with mpl, it would have been faster to just write a new method which would compile faster (see previous comments about #include's)

From: ros-users-bounces at lists.ros.org<mailto:ros-users-bounces at lists.ros.org> [mailto:ros-users-bounces at lists.ros.org<mailto:ros-users-bounces at lists.ros.org>] On Behalf Of Brian Gerkey
Sent: Thursday, February 20, 2014 11:44 AM
To: User discussions
Subject: Re: [ros-users] ROS usability -> boost

That's great feedback. We were just discussing this issue the other day and came to the conclusion that we should start new projects (e.g., ROS 2) using what's now in the standard, and only pull in boost if it becomes really necessary. The cost of this approach is that you need a reasonably modern compiler, but that seems like a good trafeoff to make.

brian.
On Feb 20, 2014 8:01 AM, <rdean at gdrs.com<mailto:rdean at gdrs.com>> wrote:
On the boost topic, I have been a boost fan for many years... until having to support multiple versions.  Recently I changed all our core to use C++0x equivalents which fixed the dependency issues, and surprisingly compiles 30% faster.  (basically boost #include's a massive number of headers, while gcc equivalents do not)

This is an important point for moving forwards with ROS simplicity in addition to API and tutorial type usability. Make use of what the compiler provides while avoiding "tricks" in the language (some template solutions out on the web are cool, but eat up compile time and complexity. *cough*mpl*cough*). Even something as common as Boost has potentially nasty dependency and code complexity issues. Maybe retrofitting roscpp is a poor use of resources at this time, but moving forwards with new code or ROS2.0 it makes sense.

-----Original Message-----
From: ros-users-bounces at lists.ros.org<mailto:ros-users-bounces at lists.ros.org> [mailto:ros-users-bounces at lists.ros.org<mailto:ros-users-bounces at lists.ros.org>] On Behalf Of kamicc olo
Sent: Thursday, February 20, 2014 8:56 AM
To: User discussions
Subject: Re: [ros-users] ROS usability

Been facing an issue with SSE and ARM for some time either. Not mentioning libboost...

On 2/20/14, Arkapravo Bhaumik <arkapravobhaumik at gmail.com<mailto:arkapravobhaumik at gmail.com>> wrote:
> Agree on the redundancy of packages (read xkcd zindabad) and the boost
> issues ! Have faced serious boost issues.
>
>
> On 20 February 2014 18:36, Michael Fritscher <
> michael.fritscher at telematik-zentrum.de<mailto:michael.fritscher at telematik-zentrum.de>> wrote:
>
>> Hallo everybody,
>>
>> just my 2 cents:
>>
>> In my oppinion, the ROS core is fairly well documented and quite
>> useable
>> -
>> both for beginners and advanced users. The problem are in my oppinion
>> many of the packages. Most of the packages are more or less drivers
>> for robots or middleware things. But even e.g. on the usb camera side
>> there are at least 5 different drivers (see
>> http://www.iheartrobotics.com/
>> 2010/05/testing-ros-usb-camera-drivers.html and
>> http://pharos.ece.utexas.edu/wiki/index.php/How_to_Use_a_
>> Webcam_in_ROS_with_the_gscam_Package ) - why the heck we do need at
>> least
>> 5 drivers for a simple thing like capturing webcam pictures?! I know
>> that there are different requirements, but forking isn't always the
>> best solution...
>>
>> Additionally, many plugins aren't that usable. Are little example are
>> localization using 1 or 2 video cameras. viso2_ros doesn't need sse2,
>> which is a no-go for ARM-cpus which are getting more and more
>> popular.
>> PTAM is at least compiling, but it even fail to correctly display the
>> video image (both on arm and on a normal x64 laptop). Sometimes it
>> remembers me about https://xkcd.com/927/ ...
>>
>> Another problem is in my oppinion the library-hell problem. ROS
>> packages are tightly tied with specific library version (e.g.
>> libboost) which
>> (roughly) exists only on one specific distro-version. This makes it
>> almost inpossible to use binary versions of ros on another distros.
>> Perhaps this can be solved that the binary packages depend on e.g.
>> "libboost-1.42 | roslibboost-groovy" - so either the distro-version
>> or a ros-own version can be used.
>>
>> Best regards,
>> Michael Fritscher
>>
>> --
>> ZfT - Zentrum für Telematik e.V.
>> Michael Fritscher
>> Allesgrundweg 12
>> 97218 Gerbrunn
>> Tel:  +49 (931) 3 29 29 54 - 21<tel:%2B49%20%28931%29%203%2029%2029%2054%20-%2021>
>> Email: michael.fritscher at telematik-zentrum.de<mailto:michael.fritscher at telematik-zentrum.de>
>> Web: http://www.telematik-zentrum.de
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org<mailto:ros-users at lists.ros.org>
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>>
>
>
> --
> *Arkapravo Bhaumik*
>
>
> http://mobotica.blogspot.in/p/head.html
>
_______________________________________________
ros-users mailing list
ros-users at lists.ros.org<mailto:ros-users at lists.ros.org>
http://lists.ros.org/mailman/listinfo/ros-users

-------------------------------------------------------
This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.

_______________________________________________
ros-users mailing list
ros-users at lists.ros.org<mailto:ros-users at lists.ros.org>
http://lists.ros.org/mailman/listinfo/ros-users

------------------------------------------------------

This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.

_______________________________________________
ros-users mailing list
ros-users at lists.ros.org<mailto:ros-users at lists.ros.org>
http://lists.ros.org/mailman/listinfo/ros-users

--
William Woodall
ROS Development Team
william at osrfoundation.org<mailto:william at osrfoundation.org>
http://williamjwoodall.com/

-------------------------------------------------------
This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140224/88d92c11/attachment.html>