Note,
The rdmanifest hosting may experience some downtime in the next 24 hours
while our DNS servers are being updated.
If you experience outages, you can add the following to your /etc/hosts
file:
mirror.ausparc.com 131.204.128.76
Sorry for the inconvenience.
~mc
On Fri, Aug 19, 2011 at 12:06, William Woodall <
wjwwood@gmail.com> wrote:
> There has been a disruption of my rdmanifest hosting. So, if you are
> having trouble with rosdep installs try again in a minute.
>
> Sorry about that,
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> William Woodall
> Graduate Software Engineering
> Auburn University
> w@auburn.edu
> wjwwood@gmail.com
> williamjwoodall.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> On Fri, Aug 19, 2011 at 11:39 AM, William Woodall <wjwwood@gmail.com>wrote:
>
>> Nick, I usually comment out any offending lines in my .bashrc and then
>> sudo mv /opt/local /opt/_local when I wanted to "disable" macports
>> temporarily. I think my friend John had macports installed at the same time
>> with homebrew, but I know he had problems with a few of the homebrew
>> installs linking against macports libraries rather than built-in ones. I
>> have yet to extensively test using macports and homebrew at the same time to
>> see if that is a viable option. But I don't really see a reason for
>> Homebrew if you are using macports.
>>
>> Mark, most of the time I am looking to macports for fixes to homebrew
>> packages, in fact many homebrew formulas reference macports patches.
>>
>> Using Homebrew OR macports seems very possible.
>>
>> The biggest difference between macports and homebrew in my mind is the use
>> of built-in system libraries. Because I am using the built-in python2.7
>> from apple, I can use wxPython-2.9.2-py27 binary install from wxPython's
>> site and I can install many of the python libraries from pip. This saves me
>> a lot of headache and the user a lot of build time. Additionally, all of
>> the X11 library dependencies are already satisfied by apple, and many others
>> like apr and libiconv just to name a few. So with macports you end up
>> building a lot of stuff you real didn't have to. This isn't bad or
>> anything, and using Homebrew is still what I would consider an experiment.
>> There are definitely some problems with lacking package support and
>> universal build support for Formulas in homebrew. I am still not convinced
>> homebrew is going to be able to satisfy all our dependencies, but I am
>> hoping it does because of the fact that it uses built-in libraries as much
>> as possible.
>>
>> --
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> William Woodall
>> Graduate Software Engineering
>> Auburn University
>> w@auburn.edu
>> wjwwood@gmail.com
>> williamjwoodall.com
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>> On Fri, Aug 19, 2011 at 11:12 AM, Mark Moll <mmoll@rice.edu> wrote:
>>
>>> I would imagine that many of the Lion-specific fixes that William is
>>> creating through Homebrew recipes could be ported back to corresponding
>>> MacPorts Portfiles. It’d be nice if there was some way in ROS to use either
>>> Homebrew or MacPorts to satisfy dependencies.
>>>
>>> On Aug 19, 2011, at 11:04 AM, Nicholas Butko wrote:
>>>
>>> > William,
>>> >
>>> > Do you have any idea how the Homebrew solution interacts with macports?
>>> I have a pretty significant port install base, and I'd like to avoid
>>> conflicting library versions, conflicting python versions, etc. if possible.
>>> >
>>> > One thing that's really important to me on macports right now is the
>>> qtconsole version of ipython, which has quite a few dependencies including
>>> qt4 and pyqt4; according to the internet, these are quite painful to install
>>> without macports. Do you know if there is a good homebrew solution for
>>> ipython and qtconsole?
>>> >
>>> > --Nick
>>> >
>>> > On Thu, Aug 18, 2011 at 9:22 PM, Jonathan Bohren <
>>> jonathan.bohren@gmail.com> wrote:
>>> > Yeah, I've also been following this, keep it up!
>>> >
>>> > (there have been several people at JHU asking me about ROS support on
>>> OS X)
>>> >
>>> > -j
>>> >
>>> >
>>> > On Fri, Aug 19, 2011 at 12:20 AM, Matthew Willis <funkinitup@gmail.com>
>>> wrote:
>>> > Just wanted to say that I have been following this thread and wanted to
>>> congratulate William on his great work :-)
>>> >
>>> > I look forward to using homebrew and ROS on my Lion install in the
>>> future :-)
>>> >
>>> > - Matt
>>> >
>>> >
>>> > On 19/08/2011, at 1:45 PM, William Woodall wrote:
>>> >
>>> >> Me too, after a clean install of Lion it still works.
>>> >>
>>> >> Though it is always proceed with caution.
>>> >>
>>> >> YMMV,
>>> >>
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> William Woodall
>>> >> Graduate Software Engineering
>>> >> Auburn University
>>> >> w@auburn.edu
>>> >> wjwwood@gmail.com
>>> >> williamjwoodall.com
>>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Aug 18, 2011 at 10:37 PM, Serge Stinckwich <
>>> serge.stinckwich@gmail.com> wrote:
>>> >> Great work William.
>>> >>
>>> >> I will try do to the same soon. I'm just a bit anxious about
>>> >> installing Lion at the moment because i'm using refit with an Ubuntu
>>> >> partition.
>>> >>
>>> >> Thank you.
>>> >>
>>> >> On Fri, Aug 19, 2011 at 10:10 AM, William Woodall <wjwwood@gmail.com>
>>> wrote:
>>> >> >
>>> >> > Progress, turtlesim works.
>>> >> >
>>> >> >
>>> >> > --
>>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> > William Woodall
>>> >> > Graduate Software Engineering
>>> >> > Auburn University
>>> >> > w@auburn.edu
>>> >> > wjwwood@gmail.com
>>> >> > williamjwoodall.com
>>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >
>>> >> >
>>> >> > On Thu, Aug 18, 2011 at 2:42 PM, William Woodall <wjwwood@gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> For those that are interested, here is an update on the ROS
>>> Electric on OS X with homebrew experiment.
>>> >> >> The biggest change so far is that I have switched to the stock
>>> apple python2.7 and forced ROS to build as universal (i386 and x86_64).
>>> Currently, the latest instructions on github.com should let you
>>> replicate what I have to far. Additionally, I have updated the
>>> apply-patches script to check the version of the stack and the version of
>>> the patch for that stack to warn you of mismatches, but it the patches
>>> should work for the latest round of updates on the electric tag (ros 1.6.1,
>>> et. all). You will want to read the "If you are updating your setup"
>>> section here:
>>> https://github.com/wjwwood/ros-osx/tree/master/electric-lion-homebrew
>>> >> >> I have also tried to test all the packages in the Desktop-Full
>>> variant and list their status at the end of the documentation. Here is a
>>> snapshot of that list:
>>> >> >>
>>> >> >> The following stacks are known to build:
>>> >> >>
>>> >> >> assimp
>>> >> >> bond_core
>>> >> >> bullet
>>> >> >> common_msgs
>>> >> >> common_rosdeps
>>> >> >> diagnostics
>>> >> >> driver_common
>>> >> >>
>>> >> >> dynamic_reconfigure has been tested and works (after patch)
>>> >> >>
>>> >> >> eigen
>>> >> >> executive_smach
>>> >> >> filters
>>> >> >> geometry
>>> >> >> geometry_experimental
>>> >> >> laser_pipeline
>>> >> >> nodelet_core
>>> >> >> orocos kinematics dynamics
>>> >> >> pluginlib
>>> >> >> ros
>>> >> >> ros_comm
>>> >> >> xacro
>>> >> >>
>>> >> >> The following are known not to build, and why:
>>> >> >>
>>> >> >> common_tutorials &
>>> >> >> ros_tutorials
>>> >> >>
>>> >> >> turtlesim
>>> >> >>
>>> >> >> Fails on a linking error with wx, wx isn't building universal atm.
>>> >> >>
>>> >> >> diagnostics_monitors
>>> >> >>
>>> >> >> wx
>>> >> >>
>>> >> >> executive_smach
>>> >> >>
>>> >> >> wx
>>> >> >>
>>> >> >> image_common
>>> >> >>
>>> >> >> camera calibration parsers
>>> >> >>
>>> >> >> libyaml-cpp is not built as a universal atm, needs a homebrew patch
>>> >> >>
>>> >> >> image_pipeline
>>> >> >>
>>> >> >> rosdep opencv2.3 not satisfied (brew has opencv2.2, need to patch
>>> for 2.3)
>>> >> >>
>>> >> >> image transport plugins
>>> >> >>
>>> >> >> rosdep opencv2.3 not satisfied
>>> >> >>
>>> >> >> navigation
>>> >> >>
>>> >> >> rosdep's failed to install: netpbm and fltk
>>> >> >>
>>> >> >> perception_pcl
>>> >> >>
>>> >> >> Errors with PCL (I will report these asap)
>>> >> >>
>>> >> >> physics_ode
>>> >> >>
>>> >> >> opende fails with /usr/bin/gm4:configure.in:373: bad expression in
>>> eval (bad input): 30 > libccd@:>@
>>> >> >>
>>> >> >> robot_model
>>> >> >>
>>> >> >> collada_parser fails with linking error, more details asap
>>> >> >>
>>> >> >> rx
>>> >> >>
>>> >> >> rosdeps wxwidgets, python-gtk not satisfied
>>> >> >>
>>> >> >> simulator_gazebo
>>> >> >>
>>> >> >> wx
>>> >> >>
>>> >> >> simulator_stage
>>> >> >>
>>> >> >> fltk
>>> >> >>
>>> >> >> slam_gmapping
>>> >> >>
>>> >> >> netpbm and fltk
>>> >> >>
>>> >> >> stage
>>> >> >>
>>> >> >> fltk
>>> >> >>
>>> >> >> vision_opencv
>>> >> >>
>>> >> >> opencv2.3 rosdep
>>> >> >>
>>> >> >> Other known dependency issues:
>>> >> >>
>>> >> >> libxml2
>>> >> >>
>>> >> >> is not built universal, not a problem yet, but may need to be
>>> patched
>>> >> >>
>>> >> >> libogg
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> theora
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> vtk
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> tbb
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> hdf5
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> qhull
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> graphviz
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> fltk
>>> >> >>
>>> >> >> doesn't build
>>> >> >>
>>> >> >> ffmpeg
>>> >> >>
>>> >> >> is not built universal
>>> >> >>
>>> >> >> graphicsmagick
>>> >> >>
>>> >> >> Fails
>>> >> >>
>>> >> >> Hopefully I can work out the wxWidgets universal build soon and
>>> mark several of those off the list.
>>> >> >> --
>>> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >> William Woodall
>>> >> >> Graduate Software Engineering
>>> >> >> Auburn University
>>> >> >> w@auburn.edu
>>> >> >> wjwwood@gmail.com
>>> >> >> williamjwoodall.com
>>> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Aug 15, 2011 at 2:37 PM, William Woodall <
>>> wjwwood@gmail.com> wrote:
>>> >> >>>
>>> >> >>> Yeah, so I am actually back to the built-in python on my setup,
>>> because of wxPython, but that means we will have to source install a few of
>>> the python libraries, off the top of my head sip and pycairo don't work with
>>> pip because they don't follow the `python setup.py install` method. We'll
>>> see how it goes, I will try to get the latest revision up on github soon,
>>> but I have some other work to do today.
>>> >> >>> Thanks,
>>> >> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>> William Woodall
>>> >> >>> Graduate Software Engineering
>>> >> >>> Auburn University
>>> >> >>> w@auburn.edu
>>> >> >>> wjwwood@gmail.com
>>> >> >>> williamjwoodall.com
>>> >> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>
>>> >> >>>
>>> >> >>> On Sun, Aug 14, 2011 at 8:24 PM, Ken Conley <kwc@willowgarage.com>
>>> wrote:
>>> >> >>>>
>>> >> >>>> On Sun, Aug 14, 2011 at 4:31 PM, William Woodall <
>>> wjwwood@gmail.com> wrote:
>>> >> >>>> > Well, so far no, but looking ahead I think I need it for proper
>>> numpy,
>>> >> >>>> > matplotlib, scipy, and iPython support:
>>> >> >>>> >
>>> http://www.thisisthegreenroom.com/2011/installing-python-numpy-scipy-matplotlib-and-ipython-on-lion/
>>> >> >>>> > If it turns out this was only necessary these days then I will
>>> roll back to
>>> >> >>>> > the built-in python.
>>> >> >>>>
>>> >> >>>> I've installed numpy both from source and pip with the vanilla
>>> Apple
>>> >> >>>> Python 2.6 and had the same result: successful install, though
>>> two of
>>> >> >>>> the 100+ unit tests fail. I didn't really bother looking into
>>> the
>>> >> >>>> nature of the failing tests, but I didn't see anything that would
>>> >> >>>> indicate that Python 2.6 was at issue.
>>> >> >>>>
>>> >> >>>> - Ken
>>> >> >>>>
>>> >> >>>> > --
>>> >> >>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> > William Woodall
>>> >> >>>> > Graduate Software Engineering
>>> >> >>>> > Auburn University
>>> >> >>>> > w@auburn.edu
>>> >> >>>> > wjwwood@gmail.com
>>> >> >>>> > williamjwoodall.com
>>> >> >>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> >
>>> >> >>>> >
>>> >> >>>> > On Sun, Aug 14, 2011 at 5:29 PM, Ken Conley <
>>> kwc@willowgarage.com> wrote:
>>> >> >>>> >>
>>> >> >>>> >> Thanks for looking into this.
>>> >> >>>> >>
>>> >> >>>> >> On a separate issue, what is the reason for the brew install
>>> of
>>> >> >>>> >> Python? Is there some issue with the default Apple install?
>>> >> >>>> >>
>>> >> >>>> >> thanks,
>>> >> >>>> >> - Ken
>>> >> >>>> >>
>>> >> >>>> >> On Sun, Aug 14, 2011 at 3:09 PM, William Woodall <
>>> wjwwood@gmail.com>
>>> >> >>>> >> wrote:
>>> >> >>>> >> > Looks like the way brew is linking it or using libtool
>>> causes the
>>> >> >>>> >> > libgtest.la file to never be created, because installing
>>> manually from
>>> >> >>>> >> > source works for me. I filed a ticket on Homebrew's github
>>> >> >>>> >> > here: https://github.com/mxcl/homebrew/issues/7009
>>> >> >>>> >> > In the mean time I have created a sourcedep for it and when
>>> it is fixed
>>> >> >>>> >> > by
>>> >> >>>> >> > homebrew I will switch to using that again. The latest
>>> patches should
>>> >> >>>> >> > work.
>>> >> >>>> >> > Also as a side note for others, I find it useful to make a
>>> copy of ~/ros
>>> >> >>>> >> > before the patching step (something like cp -r ~/ros
>>> ~/clean_ros) so I
>>> >> >>>> >> > can
>>> >> >>>> >> > test new patches without downloading a new ros each time. I
>>> use this:
>>> >> >>>> >> > `rm
>>> >> >>>> >> > -rf ~/ros; cp -r ~/clean_ros ~/ros` to "reset" my ros.
>>> >> >>>> >> > Let me know if that works,
>>> >> >>>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> >> > William Woodall
>>> >> >>>> >> > Graduate Software Engineering
>>> >> >>>> >> > Auburn University
>>> >> >>>> >> > w@auburn.edu
>>> >> >>>> >> > wjwwood@gmail.com
>>> >> >>>> >> > williamjwoodall.com
>>> >> >>>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> >> >
>>> >> >>>> >> >
>>> >> >>>> >> > On Sun, Aug 14, 2011 at 3:57 PM, William Woodall <
>>> wjwwood@gmail.com>
>>> >> >>>> >> > wrote:
>>> >> >>>> >> >>
>>> >> >>>> >> >> I had not tested them, but I can confirm that doesn't work
>>> for me
>>> >> >>>> >> >> either.
>>> >> >>>> >> >> I have had weird stuff happen to me on OS X with gtest
>>> before, this is
>>> >> >>>> >> >> something we'll have to investigate.
>>> >> >>>> >> >> Thanks,
>>> >> >>>> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> >> >> William Woodall
>>> >> >>>> >> >> Graduate Software Engineering
>>> >> >>>> >> >> Auburn University
>>> >> >>>> >> >> w@auburn.edu
>>> >> >>>> >> >> wjwwood@gmail.com
>>> >> >>>> >> >> williamjwoodall.com
>>> >> >>>> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> >> >>
>>> >> >>>> >> >>
>>> >> >>>> >> >> On Sun, Aug 14, 2011 at 2:58 PM, Ken Conley <
>>> kwc@willowgarage.com>
>>> >> >>>> >> >> wrote:
>>> >> >>>> >> >>>
>>> >> >>>> >> >>> Thanks for putting this together.
>>> >> >>>> >> >>>
>>> >> >>>> >> >>> On your setup, are the tests working? I'm having trouble
>>> getting
>>> >> >>>> >> >>> rosbuild to work with the gtest provided by brew. I've
>>> seen this same
>>> >> >>>> >> >>> error on two different OS X machines (Lion, Snow Leopard),
>>> though I
>>> >> >>>> >> >>> haven't reset things to go through your instructions step
>>> by step:
>>> >> >>>> >> >>>
>>> >> >>>> >> >>> (output snippet, e.g. 'roscd test_roslib; make test')
>>> >> >>>> >> >>>
>>> >> >>>> >> >>> make[4]: *** No rule to make target `/usr/local/lib/
>>> libgtest.la
>>> >> >>>> >> >>> -D_THREAD_SAFE', needed by `../test_package'.
>>> >> >>>> >> >>> make[4]: Target `CMakeFiles/test_package.dir/build' not
>>> remade because
>>> >> >>>> >> >>> of errors.
>>> >> >>>> >> >>> make[3]: *** [CMakeFiles/test_package.dir/all] Error 2
>>> >> >>>> >> >>> [ 0%] Built target clean-test-results
>>> >> >>>> >> >>> make[4]: *** No rule to make target `/usr/local/lib/
>>> libgtest.la
>>> >> >>>> >> >>> -D_THREAD_SAFE', needed by `../test/utest'.
>>> >> >>>> >> >>> make[4]: Target `CMakeFiles/test/utest.dir/build' not
>>> remade because
>>> >> >>>> >> >>> of
>>> >> >>>> >> >>> errors.
>>> >> >>>> >> >>> make[3]: *** [CMakeFiles/test/utest.dir/all] Error 2
>>> >> >>>> >> >>> make[3]: Target `CMakeFiles/test.dir/all' not remade
>>> because of
>>> >> >>>> >> >>> errors.
>>> >> >>>> >> >>> make[2]: *** [CMakeFiles/test.dir/rule] Error 2
>>> >> >>>> >> >>> make[2]: Target `test' not remade because of errors.
>>> >> >>>> >> >>> make[1]: *** [test] Error 2
>>> >> >>>> >> >>>
>>> >> >>>> >> >>>
>>> >> >>>> >> >>> On Sun, Aug 14, 2011 at 12:48 PM, William Woodall <
>>> wjwwood@gmail.com>
>>> >> >>>> >> >>> wrote:
>>> >> >>>> >> >>> > Hi everyone, I just wanted to let everyone know that we
>>> (my
>>> >> >>>> >> >>> > colleagues
>>> >> >>>> >> >>> > and
>>> >> >>>> >> >>> > I) have started an effort to document and fix any issues
>>> related
>>> >> >>>> >> >>> > installing
>>> >> >>>> >> >>> > ROS Electric Emys on OS X 10.7 Lion using Homebrew
>>> instead of
>>> >> >>>> >> >>> > Macports.
>>> >> >>>> >> >>> > We
>>> >> >>>> >> >>> > are creating documentation and patches as we go in our
>>> github.com
>>> >> >>>> >> >>> > repository
>>> >> >>>> >> >>> > located here:
>>> >> >>>> >> >>> >
>>> >> >>>> >> >>> >
>>> >> >>>> >> >>> > Instructions:
>>> https://github.com/wjwwood/ros-osx/blob/master/electric-lion-homebrew/README.md
>>> >> >>>> >> >>> > Repository: https://github.com/wjwwood/ros-osx
>>> >> >>>> >> >>> > The instructions linked above walk through setting up
>>> ROS Electric
>>> >> >>>> >> >>> > on a
>>> >> >>>> >> >>> > clean Lion install using the Homebrew
>>> >> >>>> >> >>> > (http://mxcl.github.com/homebrew/)
>>> >> >>>> >> >>> > package management system. I would encourage anyone who
>>> is
>>> >> >>>> >> >>> > interested
>>> >> >>>> >> >>> > to
>>> >> >>>> >> >>> > give it a try and report any problems you run into
>>> either on this
>>> >> >>>> >> >>> > mailing
>>> >> >>>> >> >>> > list or as an issue on the github
>>> >> >>>> >> >>> > site: https://github.com/wjwwood/ros-osx/issues. We
>>> would also
>>> >> >>>> >> >>> > welcome
>>> >> >>>> >> >>> > any
>>> >> >>>> >> >>> > help in the form of resolving issues, documentation, and
>>> patches.
>>> >> >>>> >> >>> > Currently, the ros, ros_comm, common_msgs, and geometry
>>> stacks are
>>> >> >>>> >> >>> > known to
>>> >> >>>> >> >>> > work. This includes some pretty commonly used packages
>>> like most of
>>> >> >>>> >> >>> > the
>>> >> >>>> >> >>> > command line tools and tf. We will be continuously
>>> updating this
>>> >> >>>> >> >>> > repository
>>> >> >>>> >> >>> > so keep an eye on it if you are looking for something
>>> specific.
>>> >> >>>> >> >>> > Thanks,
>>> >> >>>> >> >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> >> >>> > William Woodall
>>> >> >>>> >> >>> > Graduate Software Engineering
>>> >> >>>> >> >>> > Auburn University
>>> >> >>>> >> >>> > w@auburn.edu
>>> >> >>>> >> >>> > wjwwood@gmail.com
>>> >> >>>> >> >>> > williamjwoodall.com
>>> >> >>>> >> >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >> >>>> >> >>> >
>>> >> >>>> >> >>> > _______________________________________________
>>> >> >>>> >> >>> > ros-users mailing list
>>> >> >>>> >> >>> > ros-users@code.ros.org
>>> >> >>>> >> >>> > https://code.ros.org/mailman/listinfo/ros-users
>>> >> >>>> >> >>> >
>>> >> >>>> >> >>> >
>>> >> >>>> >> >>> _______________________________________________
>>> >> >>>> >> >>> ros-users mailing list
>>> >> >>>> >> >>> ros-users@code.ros.org
>>> >> >>>> >> >>> https://code.ros.org/mailman/listinfo/ros-users
>>> >> >>>> >> >>
>>> >> >>>> >> >
>>> >> >>>> >> >
>>> >> >>>> >> > _______________________________________________
>>> >> >>>> >> > ros-users mailing list
>>> >> >>>> >> > ros-users@code.ros.org
>>> >> >>>> >> > https://code.ros.org/mailman/listinfo/ros-users
>>> >> >>>> >> >
>>> >> >>>> >> >
>>> >> >>>> >> _______________________________________________
>>> >> >>>> >> ros-users mailing list
>>> >> >>>> >> ros-users@code.ros.org
>>> >> >>>> >> https://code.ros.org/mailman/listinfo/ros-users
>>> >> >>>> >
>>> >> >>>> >
>>> >> >>>> > _______________________________________________
>>> >> >>>> > ros-users mailing list
>>> >> >>>> > ros-users@code.ros.org
>>> >> >>>> > https://code.ros.org/mailman/listinfo/ros-users
>>> >> >>>> >
>>> >> >>>> >
>>> >> >>>> _______________________________________________
>>> >> >>>> ros-users mailing list
>>> >> >>>> ros-users@code.ros.org
>>> >> >>>> https://code.ros.org/mailman/listinfo/ros-users
>>> >> >>>
>>> >> >>
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > ros-users mailing list
>>> >> > ros-users@code.ros.org
>>> >> > https://code.ros.org/mailman/listinfo/ros-users
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Serge Stinckwich
>>> >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>>> >> Every DSL ends up being Smalltalk
>>> >> http://doesnotunderstand.org/
>>> >> _______________________________________________
>>> >> ros-users mailing list
>>> >> ros-users@code.ros.org
>>> >> https://code.ros.org/mailman/listinfo/ros-users
>>> >>
>>> >> _______________________________________________
>>> >> ros-users mailing list
>>> >> ros-users@code.ros.org
>>> >> https://code.ros.org/mailman/listinfo/ros-users
>>> >
>>> >
>>> > _______________________________________________
>>> > ros-users mailing list
>>> > ros-users@code.ros.org
>>> > https://code.ros.org/mailman/listinfo/ros-users
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > ros-users mailing list
>>> > ros-users@code.ros.org
>>> > https://code.ros.org/mailman/listinfo/ros-users
>>> >
>>> >
>>> > _______________________________________________
>>> > ros-users mailing list
>>> > ros-users@code.ros.org
>>> > https://code.ros.org/mailman/listinfo/ros-users
>>>
>>> --
>>> Mark Moll
>>>
>>>
>>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users@code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>