Menu
▾
▴
playerstage-developers — Developers list
You can subscribe to this list here.
| 2002 |
Jan
(5) |
Feb
(28) |
Mar
(9) |
Apr
(15) |
May
(17) |
Jun
(58) |
Jul
(12) |
Aug
(25) |
Sep
(10) |
Oct
(4) |
Nov
(52) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(13) |
Feb
(19) |
Mar
(8) |
Apr
(21) |
May
(34) |
Jun
(10) |
Jul
(26) |
Aug
(52) |
Sep
(14) |
Oct
(36) |
Nov
(39) |
Dec
(4) |
| 2004 |
Jan
(2) |
Feb
(6) |
Mar
(28) |
Apr
(29) |
May
(53) |
Jun
(54) |
Jul
(54) |
Aug
(49) |
Sep
(42) |
Oct
(32) |
Nov
(58) |
Dec
(7) |
| 2005 |
Jan
(24) |
Feb
(21) |
Mar
(40) |
Apr
(102) |
May
(73) |
Jun
(38) |
Jul
(70) |
Aug
(11) |
Sep
(18) |
Oct
(38) |
Nov
(33) |
Dec
(3) |
| 2006 |
Jan
(21) |
Feb
(74) |
Mar
(79) |
Apr
(86) |
May
(75) |
Jun
(45) |
Jul
(74) |
Aug
(57) |
Sep
(60) |
Oct
(12) |
Nov
(20) |
Dec
(18) |
| 2007 |
Jan
(16) |
Feb
(53) |
Mar
(31) |
Apr
(35) |
May
(121) |
Jun
(72) |
Jul
(22) |
Aug
(46) |
Sep
(45) |
Oct
(71) |
Nov
(93) |
Dec
(66) |
| 2008 |
Jan
(32) |
Feb
(87) |
Mar
(116) |
Apr
(58) |
May
(49) |
Jun
(106) |
Jul
(95) |
Aug
(74) |
Sep
(101) |
Oct
(84) |
Nov
(59) |
Dec
(55) |
| 2009 |
Jan
(73) |
Feb
(53) |
Mar
(94) |
Apr
(82) |
May
(106) |
Jun
(147) |
Jul
(160) |
Aug
(77) |
Sep
(28) |
Oct
(57) |
Nov
(15) |
Dec
(37) |
| 2010 |
Jan
(39) |
Feb
(38) |
Mar
(33) |
Apr
(25) |
May
(29) |
Jun
(92) |
Jul
(55) |
Aug
(42) |
Sep
(19) |
Oct
(17) |
Nov
(15) |
Dec
(10) |
| 2011 |
Jan
(14) |
Feb
(12) |
Mar
(9) |
Apr
(2) |
May
(7) |
Jun
(6) |
Jul
(6) |
Aug
(11) |
Sep
(11) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2012 |
Jan
(5) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(8) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(9) |
| 2013 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(21) |
May
(43) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
(21) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(8) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(1) |
Mar
(10) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: benoit g. <ben...@ou...> - 2017-05-06 11:15:54
|
Hello, I use player stage. I program a robot with random linear speed and change it in random moment. I want to record the speed only every each second. Il search how to do it since a long time, if you have any idea. Thanks a lot ________________________________ De : benoit gallon Envoyé : samedi 6 mai 2017 10:56:23 À : pla...@li... Objet : question Hello, I use player stage. I program a robot with random linear speed and change it in random moment. I want to record the speed only avec second. Il search how to do it since a long time, if you have any idea. Thanks a lot |
|
From: benoit g. <ben...@ou...> - 2017-05-06 10:56:34
|
Hello, I use player stage. I program a robot with random linear speed and change it in random moment. I want to record the speed only avec second. Il search how to do it since a long time, if you have any idea. Thanks a lot |
|
From: Rich M. <jp...@gm...> - 2017-04-08 17:44:22
|
I'm happy to announce the release of Player 3.1.0. This release contains a number of bugfixes and new features since the Player 3.0.2 release in 2010. It's also the first Player release to be hosted on GitHub, as the migration of the project continues from its old home at SourceForge. I'd like to thank everyone who contributed bug reports, fixes, enhancements, and documentation over the course of the release. The release announcement and code are available at https://github.com/playerproject/player/releases/tag/release-3-1-0 Rich --- Brian Gerkey (3): Removed ARNL parameters, which were accidentally included. dummy change, to check hudson swapped include ordering to fix build on OSX Geoffrey Biggs (25): Post-release version bump Applied patch #2836953: grid map driver Applied patch #2839064: New Swissranger driver Applied patch #2844290: New rangerposeinterpolator driver Applied patch #2847168: core: nanosleep instead of usleep Applied patch #2847832: Extended map interface Applied patch #2851088: New dio interface driver Applied patch #2861887: Added checks for non-existent policies. Fixes for compiling on Windows, part 1 Fixes for compiling on Windows, part 2: Make it work with pykg-config. Fixed XSensMT. Fixed incorrect checking of pkg-config versions. Updated changelog for release 3.0.1 Fixed typo in flexiport pkg-config version spec Applied patch #2993776: WIN32 compilation issues patch Applied patch #2997935: zero sized requests once again Applied patch #3007996: Strings created by EncodeHex are not null-terminated Applied patch #3008884: Exception in C++ examples catched by value, not by reference Applied patch #2916187: Python bindings for libplayerc++ build fixup Fixed bug #3013281: simulation->GetProperty bug Fixed spelling error Corrected name of driver register function Updated to 2.0 api Reverted munged commit 8982 Upgraded hokuyo_aist to 2.0 API Updated Flexiport and HokuyoAIST drivers to use new libraries Kevin Nickels (1): Added line to allow python to use pointers (cr. stefano franchi) Nate Koenig (1): Removed some build warnings Rich (1): Merge pull request #5 from NickelsLab/master Rich Mattes (170): Applied patch 3010358: Player SVN trunk: small improvements for camera drivers Applied patch 3018514: Localize interface visualization in playerv Applied patch 3019070: Faster map rendering in playerv Updated ChangeLog for 3.0.2 release Fixed header detection for linuxwifi driver Fixed bug that prevented server from printing driver list when compiled in Release mode Applied patch #3025619: Player SVN trunk: compatibility patch Fixed bug #2990684: Player 3.0.1 Festival driver fails Fixed bug #3006544: Driver Mapfile load the image incorrectly Applied patch #2948822: hemisson driver Applied patch #3014384: camera1394: corrected documentation, use libdc1394s debayer Applied patch #3027374: Player SVN: camera1394 libdc1394-1 compatibility restored Applied patch #3029974: Player SVN: extended camera interface Applied patch #3034305: Player SVN: more camera fixes Applied patch #3035834: Fix laserbar driver Applied patch #3035844: Add basic intensity reporting for sicks3000 driver Applied patch #3016030: Multiline Drawing for Player and Stage Applied patch #3037148: Player: Fix allocation bug in fakelocalize driver Applied patch #3040302: Canon Powershot driver and other fixes Added configurable library install dir suffix to override architecture detection Lots of documentation fixes Applied patch #3040823: huge improvements in camerav4l2 driver Applied patch 3043948: New Pioneer parameters (including Seekur and Seekur Jr.) Applied patch #3043954: fixes for saphconv (for reading Pioneer parameters) Applied patch #3044485: Player SVN: camerav4l2 again Applied patch #3046846: Corrects localize interface to full covariance matrix Applied patch #3048122: Player SVN: Maemo Linux compat. patch for camera drivers Applied patch #3055165: Player SVN: request forwarding for imgcmp and imgsave Applied patch #3046090: Some more WIN32 compilation issues, made modificatons to fix other compile errors Applied patch #3057363: [Player driver]Movirobotic's mBase robot Applied patch #3070111: Player SVN: missing comment in def resulted in error in docs Applied patch #3043954: fixes for saphconv (for reading Pioneer parameters) (take 2) Applied patch #3073263: Updated amtecM5 for compilation with gcc 4.4.3 Re-enable "laserfeature" driver and update documentation section Fixed bug 3027542: Phidget drivers 2.1.7 Allow CMake 2.6 boost checking routines to be used in CMake 2.8 Fix conditional boost search to maintain compatibility with CMake 2.6 Applied patch #3085195: Compile with local libphidget installation Updated unicapimage to Player 3.0 ThreadedDriver model. Changed unicapimage CMakeLists.txt to look for libunicap.pc. Fixed bogus assertion that was causing PlayerCam to crash. Applied patch #3088062: Player: Util playerv: Lower Z-Order for map visualization Applied patch #3089823: ActArray acceleration config added Applied patch #3091932: Fixed unit conversions in sicklms200 Fixed oceanserver compile errors against Gearbox 9.11 Applied patch #3088069: Player: Introduce flip option to hokuyo_aist. Also added min/max angle flipping when the readings are inverted. Applied patch #3055958: Adds uncertrainty ellipsis for localization to utils Forgot to add new source files from patch #3055958 Changes to playercam: now supports MONO16 in addition ot MONO8 and RGB888 compression Update to playernav to use 6-element localize covarience matrix Applied patch to dynamically resize map_points array if it fills up New driver: wlanscan Applied patch #3134439: differential driver 2xPosition1d --> position2d Applied patch #3134435: Lego NXT driver Removed hard requirement on libdbs_sd for libphidget drivers Applied patch #2948635: Extended Kalman Filter localization with vector map Rangertolaser now publishes range and intensity measurements in the same messages Added uint8_t* to recognized python array types, camera imagedata now accessible from playerc python bindings Fixed bug #3137518: playerc_wrap.h requires #include stdint.h Fixed endian.h build error for OS X in NXT driver Fixed typedef build error for OS X in ekfvloc driver First pass at a stereoproxy for playercc Added stereoproxy.cc sane initialization of frame counter Converted to Player-3.0 driver model Documentation and windows compile fixes Lots of documentation fixes Added cmake tutorial, restored automake tutorial, added plugin interface tutorial Changed OS X Plugin makefile to build a .so instead of a .dylib Fixed playerc++ localize covarience, changed doc upload script to reflect new SF project paths Applied patch #3175505: Player starts alwayson drivers before listening to TCP ports Fixed CMake scripts for CMake 2.8.4 Applied patch #3296942: diocmd clk signal generation ability Applied patch #3295824: libguile-based scripting engine for Player server side Fixed casting bug in AIO log reading Applied patch #3305455: postgis and postlog building problems with latest postgresql Applied patch #3305527: Solaris compatible patch again Fixed typo in PLAYER_REQ_CAPABILITIES definition, ran sed to fix instances of typo, and added capability handlers to several drivers Re-ran sed without clobbering the svn internal files, capabilities request typo should be sorted out now Added documentation to the playerprop utility Fixed capabilities typo in libplayerc New driver: kinect Updated documentation build system to doxygen 1.7, and added custom css and layout files Changes to playernav: removed declarations from inside of assert() calls (in case player is compiled with -DNDEBUG), and changed behavior so it exits cleanly when connection to Player fails instead of bombing on an assertion Applied patch #3308766: Exposes the c points from ranger into the c++ code Fixed bug #3314514: rmp driver using canlib got rid of extra output during initialization Updated playersd to player 3.1, compiles again Added error checking to file opening code in wavefront, added documentation for update_rate parameter in mricp Fixed sonar geom segfaults in readlog Added vmapfile format to vmapfile driver description, cleaned up indentation in gridmap.h, addded a couple of comments to the TimedRequest() function in libplayercore Applied patch #3317615: hokuyo_aist does not handle hardware timestamps properly Applied patch #3363888: goto driver turns the long way really fast sometimes Fixed bug #3365450: rmp driver has default max_yawspeed in degrees Added capability requests to roomba and create drivers. Added position2d odometry set/reset to roomba and create drivers. Moved search for canlib to searchforstuff.cmake Separated CAN functionality in segwayrmp driver, driver can now build usb-only Added capability requests to the segwayrmp driver Small fixes to roomba 500 odometry, fixes to roomba and create set/reset odometry commands Applied patch #3385742: yet another compatibility patch Applied patch #3384865: hokuyo_aist: hw timestamps conflicts power-on-startup Applied patch #3389780: MacOSX compatibility patch Added CAPBILTIES_REQ define for backwards compatibility corrected incorrect spelling Applied patch #3392851: ptz sonyevid30 driver memory corruption Fixed bug #3394172: Fix to allow player to load plugins from /usr/local/lib64 Applied patch #3404769: int64_t values in 32-bits machines Fixed bug where playerc python bindings try to build when python development libraries are not available. Now checks for swig AND the PythonLibs before trying to enable python bindings Applied patch #3420949: Adding Euler offset function to IMU interface. Applied patch #3432662: Sparkfun Razor-IMU Driver Reject razorimu on windows, it requires termios.h Add includes to use struct timeval on windows Fixed Bug #3442143: bug in snd driver. SND now uses config file length and angle types Applied Patch #3464033: Fixing full state of RazorIMU Applied Patch #3436139: Fix typo in bpsproxy.cc Documentation cleanup, added configuration requests up to mixed folder Added capabilities to wavefront Applied patch #3496741: libv4l2 webcam driver for Player Applied patch #3501698: MU solaris compatibility patch libplayerc++: RangerProxy now requests configuration and geometry on startup libplayerc++: All saveframe() calls now use .pnm file format no matter what the player compression state is. libplayerc will always deflate the image and save it uncompressed Branching for release 3.1 Applied patch #3494845: Generic XBow WSN nodes driver & Cooperating Object Interface Merged r9095 into branch Applied patch #3532477: playerv uninitialised variable in pv_dev_actarray.c Fix bug #3541173: Readlog incompatible with zlib 1.2.6 flexiport driver fix for flexiport 2.0 playerc++ documentation improvements Fix bug #3548545: Adding structure player_intprop_req Invalid def file struct Applied patch #3555122: double-free issue fixed in powershot driver Applied patch #3566064: replace non-portable uint with uint32_t (again!) Applied patch #3595221: lack of header inclusion caused ntol macro was not found Fix TIME_UTC macro for boost >= 1.50 Enable player server daemonization on UNIX systems libplayerinterface: Fix dllimport/dllexport definitions Fixes for daemonization Fix compilation on clang Initial MinGW support Move timespec definition above first use More Windows build fixes Merge revisions 9097 to 9118 Fix FSF Address in GPL and LGPL copyright notices. Add a global plugin directory outside of system library search path Fix off-by-one errors in ranger boundary checking Applied patch #665: Delete error in logfile reader Applied patch #666: GPS speed, course made good and time Applied patch #667: Minor patch for ND navigation driver Applied patch #668: Remove svn:executable property from C/C++ source files Restore executable bit on scripts and utils Applied patch #669: Exception catched by value instead of by reference Removed bpsproxy.cc from playerc++, which doesn't correspond to any interfaces in Player Phidget RFID driver now compatible with phidget 2.1.8 library Applied patch #638: Add Ranger to VFH Convert GPS course reported by garminnmea from NED frame to ENU frame Ported ekfvloc to use eigen3 for matrix math, deleted non-free TCL Matrix library (matrix.h was only free for educational and non-commercial use). Applied patch #639: thread safety of playerc_client_writepacket Add explicit link to boost_system with boost_thread in boost versions greater than 1.49. According to the Boost documentation, boost thread requires boost system as of 1.52, and the link was optional as of at least 1.50. Adding the link explicitly should fix some build errors on newer distributions. Add support for hokuyoaist >= 3.0.0 Applied patch #670: Camerav4l2 support for Logilink USB 2.0 Video Grabber Applied patch #347: Bug in laserrescan driver Applied patch #625: Offline path computations with wavefront Planner interface extensions: start position command and waypoint path length Port interface and xdr generators to python 3 Only build against statgrab 0.17 or less Remove deprecated OpenCV functions Port to boost::signals2 Updated installation commands to use GNUInstallDirs Merge branch 'master' into release-3-1-patches Update version and changelog for 3.1.0 release Compile error fixes for erratic, nxt, and p2os Minor fixes for mingw32 Update changelog date Update dependencies for libplayerinterface Update readme and contributing guidelines Make the doc sidebar slightly wider Richard Vaughan (1): fixed small bug in writelog driver Toby Collett (75): Applied patch 2854278: Exit on empty config file Applied patch 2858511: Uninitialized variable in nd_plugin.cc Applid patch 2858751: writelog, readlog and dummy Applied patch 2859118: Add a timeout to a request from a driver Applied patch 2859422: Player SVN trunk: goto and globalize rq forwarding issues applied patch 2859930: Player SVN trunk: silly typos in bitlogic driver applied patch 2861644: Player SVN trunk: bunch of new drivers to implement AFSM's applied patch 2862998: Player SVN trunk: bunch of new drivers to implement AFSM's part 2, new files applied patch 2862998: Remote driver doesn't catch errors thrown in Disconnect applied aptch 2865388: playerc_read working incorrectly with data alread on inqueue applied patch 2871074: Fixed segfault in PlayerClient::Connected() applied patch 2871554: Player SVN trunk: changes to camerav4l2 applied patch 2875208: camera1394 additional set property message handling applied patch 2878824: The p2os driver doesn't report any position changes applied patch 2878829: Forward port of checksum fix for p2os applied patch 2880788: Player SVN trunk: collective ranger patch applied patch 2887703: Player 64 bit install path applied patch 2887954: writelog assertations for wifi data are too strict Applied patch 2888905: sphereptz driver added matlab/octave code form Markus Bader. This is not integrated into the build system but may be useful. fix for mclient_peek from Michael Bienia applied patch 2891142: Player SVN trunk: gripcmd WIN32 compat applied patch 2891417: cvcam.c memory overrun failure applied patch 2892294: blobtracker - new driver applied 2893427: sphereptz compat with older 2.6 kernels applied patch 2893433: camerav4l2 RGBP mode applied patch 2895525: Enable 500k baud rate in serialstream.cc to support SICKS300 didnt actually add the new files from the blobtracker patch reinstate the mbicp and nd drivers now we have confirmation of licensing change license of ptu46 to LGPL applied fixed version of 2898272: Allowing Playerinterfacegen.py to accemp multile files applied patch 2901126: Fix for PTU46 in "await" mode applied patch 2927173: Partial doxygen doc fix applied patch 2929113: Ruby Bindings install directory Applied patch 2914674: camera_save_images for JPEG cameras applied patch 2923028: requests on roomba opaque commands applied patch 2925359: New shell driver: opaquecmd applied patch 2926568: PhidgetsIFK Compilation Patch Fix timestamp intialisation in rflex sleep loop (thanks Giri) Applied patch 2933745: Opaquecmd error Applied patch 2933939: two bugs in afsm config examples Applied patch 2935385: Playerprint given number of updates Applied patch 2938899: roboteq add position1d interface and motor_control_mode conf remove additional push_back that crept in with rev 7610 Applied patch 2978343: memset in v4l2 driver Applied patch 2977971: add gstreamer camera driver Applied patch 2976583: blobtracker: overhead condition check removed Applied patch 2976557: sonyevid30: nasty bug fixed Applied patch 2974049: New driver: blobposition Applied patch 2973783: goto driver improvements Applied patch 2972780: new driver postlog some warning fixes Applied patch 2971895: cmdsplitter improvement Applied patch 2971619: roboteq add missing @endverbatim tag Applied patch 2966699: sphereptz: long awaited bug fix also includes a missing file from an earlier patch Applied patch 2965602: roomba: bumplock problem on faster onboard computers Applied patch 2964666: buggy_geom option for sonartoranger driver Applied patch 2962789: blobtodio: hard to find bug fixed Applied patch 2962513: Player SVN trunk: new searchpattern blobfinder driver also some missing files from an earlier patch Applied patch 2962489: camerav4l2: mislead comments Applied patch 2960672: camerav4l2: missing extern "C" in bayer.h Applied patch 2960594: Player SVN trunk: unhandled messages in ranger related code Applied patch 2960374: New driver (speechcmd) and new option to inhibitor Applied patch 2960235: New drivers for surveillance systems Applied patch 2955163: Player SVN trunk: one more QNX patch Applied patch 2950833: Player SVN trunk: epuck vs mricp Applied patch 2950807: Player SVN trunk: portio driver problem with sys/io.h Applied patch 2948637: scale option for vmapfile Add support to MRICP for multiple lasers (patch form Tarek Taha) Fix incorrect device address in IR publish for khepera Fix missing _PKG_ in build variable bump artk plus version updates for artoolkipplus 2.2 Add bracket that got lost when correcing variable name gz functions should use gzfile not file remove struct names from typedef in files generated for swig this fixes many warnings and some potential errors on 64bit systems. |
|
From: Toby C. <tco...@pl...> - 2017-03-28 08:10:52
|
If you are using a gazebo plugin you should be able to get access, if you are relying on the published proto streams you might have less luck. On Tue, 28 Mar 2017, 21:02 Fred Labrosse, <ff...@ab...> wrote: > Hi Toby, > > Thank you for that. > > The level of abstraction is whatever is accessible from the sensor data. > I'll have a look at what you suggest but I don't known if this will be > accessible from the sensor. I guess it must be at some level. > > Cheers, > > Fred > > > On 27/03/17 22:38, Toby Collett wrote: > > What level of abstraction are you using for accessing the pose? The > > gazebo physical links should have a > > GetRelativePose() > http://osrf-distributions.s3.amazonaws.com/gazebo/api/dev/classgazebo_1_1physics_1_1Entity.html#a20e0dee2e15afac1b8c9ffd102e80528 > > > > Otherwise you can do this yourself by fetching the parent model and its > > world pose... > > > > - Toby > > > > > > On Tue, 28 Mar 2017 at 04:26 Fred Labrosse <ff...@ab... > > <mailto:ff...@ab...>> wrote: > > > > All, > > > > I'm working on adding more functionality to gazebo so that the > interface > > to player is more feature rich! I'm doing that to get a 3D simulator > > working with player, while I still use player. > > > > I'm working based on gazebo 8. > > > > So far I have added the GPS, and that seems to work fine. > > > > I have now modified the laser interface and most of the data is now > > passed to player and a lasertoranger can make sense of it. So > (almost) > > all good. > > > > What is missing is the pose of the laser. I might be wrong but it > seems > > that gazebo only has a world pose for the laser, not a pose relative > to > > whatever it is mounted to. > > > > Anybody has any idea? Have I missed something obvious? > > > > Cheers, > > > > Fred > > > > > > -------------------------------------------------------------------- > > Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd > > myfyrwyr. > > (Arolwg Cenedlaethol y Myfyrwyr 2016) > > www.aber.ac.uk <http://www.aber.ac.uk> > > > > Top 4 UK university and best in Wales for student satisfaction > > (National Student Survey 2016) > > www.aber.ac.uk <http://www.aber.ac.uk> > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > <mailto:Pla...@li...> > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > -------------------------------------------------------------------- > Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd > myfyrwyr. > (Arolwg Cenedlaethol y Myfyrwyr 2016) > www.aber.ac.uk > > Top 4 UK university and best in Wales for student satisfaction > (National Student Survey 2016) > www.aber.ac.uk > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
|
From: Fred L. <ff...@ab...> - 2017-03-28 08:02:14
|
Hi Toby, Thank you for that. The level of abstraction is whatever is accessible from the sensor data. I'll have a look at what you suggest but I don't known if this will be accessible from the sensor. I guess it must be at some level. Cheers, Fred On 27/03/17 22:38, Toby Collett wrote: > What level of abstraction are you using for accessing the pose? The > gazebo physical links should have a > GetRelativePose() http://osrf-distributions.s3.amazonaws.com/gazebo/api/dev/classgazebo_1_1physics_1_1Entity.html#a20e0dee2e15afac1b8c9ffd102e80528 > > Otherwise you can do this yourself by fetching the parent model and its > world pose... > > - Toby > > > On Tue, 28 Mar 2017 at 04:26 Fred Labrosse <ff...@ab... > <mailto:ff...@ab...>> wrote: > > All, > > I'm working on adding more functionality to gazebo so that the interface > to player is more feature rich! I'm doing that to get a 3D simulator > working with player, while I still use player. > > I'm working based on gazebo 8. > > So far I have added the GPS, and that seems to work fine. > > I have now modified the laser interface and most of the data is now > passed to player and a lasertoranger can make sense of it. So (almost) > all good. > > What is missing is the pose of the laser. I might be wrong but it seems > that gazebo only has a world pose for the laser, not a pose relative to > whatever it is mounted to. > > Anybody has any idea? Have I missed something obvious? > > Cheers, > > Fred > > > -------------------------------------------------------------------- > Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd > myfyrwyr. > (Arolwg Cenedlaethol y Myfyrwyr 2016) > www.aber.ac.uk <http://www.aber.ac.uk> > > Top 4 UK university and best in Wales for student satisfaction > (National Student Survey 2016) > www.aber.ac.uk <http://www.aber.ac.uk> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > <mailto:Pla...@li...> > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -------------------------------------------------------------------- Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd myfyrwyr. (Arolwg Cenedlaethol y Myfyrwyr 2016) www.aber.ac.uk Top 4 UK university and best in Wales for student satisfaction (National Student Survey 2016) www.aber.ac.uk |
|
From: Toby C. <tco...@pl...> - 2017-03-27 21:38:50
|
What level of abstraction are you using for accessing the pose? The gazebo physical links should have a GetRelativePose() http://osrf-distributions.s3.amazonaws.com/gazebo/api/dev/classgazebo_1_1physics_1_1Entity.html#a20e0dee2e15afac1b8c9ffd102e80528 Otherwise you can do this yourself by fetching the parent model and its world pose... - Toby On Tue, 28 Mar 2017 at 04:26 Fred Labrosse <ff...@ab...> wrote: > All, > > I'm working on adding more functionality to gazebo so that the interface > to player is more feature rich! I'm doing that to get a 3D simulator > working with player, while I still use player. > > I'm working based on gazebo 8. > > So far I have added the GPS, and that seems to work fine. > > I have now modified the laser interface and most of the data is now > passed to player and a lasertoranger can make sense of it. So (almost) > all good. > > What is missing is the pose of the laser. I might be wrong but it seems > that gazebo only has a world pose for the laser, not a pose relative to > whatever it is mounted to. > > Anybody has any idea? Have I missed something obvious? > > Cheers, > > Fred > > > -------------------------------------------------------------------- > Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd > myfyrwyr. > (Arolwg Cenedlaethol y Myfyrwyr 2016) > www.aber.ac.uk > > Top 4 UK university and best in Wales for student satisfaction > (National Student Survey 2016) > www.aber.ac.uk > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
|
From: Fred L. <ff...@ab...> - 2017-03-27 15:26:07
|
All, I'm working on adding more functionality to gazebo so that the interface to player is more feature rich! I'm doing that to get a 3D simulator working with player, while I still use player. I'm working based on gazebo 8. So far I have added the GPS, and that seems to work fine. I have now modified the laser interface and most of the data is now passed to player and a lasertoranger can make sense of it. So (almost) all good. What is missing is the pose of the laser. I might be wrong but it seems that gazebo only has a world pose for the laser, not a pose relative to whatever it is mounted to. Anybody has any idea? Have I missed something obvious? Cheers, Fred -------------------------------------------------------------------- Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd myfyrwyr. (Arolwg Cenedlaethol y Myfyrwyr 2016) www.aber.ac.uk Top 4 UK university and best in Wales for student satisfaction (National Student Survey 2016) www.aber.ac.uk |
|
From: BiggsGeoffrey <geo...@ai...> - 2017-01-29 22:31:43
|
Hi Rich, Congratulations on two of your big events! I'll leave congratulations on getting a huge loan until it's a little smaller... Thanks for your dedication to keeping Player going and available to all. It's a lot of work, and I think we all really appreciate your hard work. Geoff ________________________________________ From: Rich Mattes <jp...@gm...> Sent: Monday, 30 January 2017 5:45 a.m. To: pla...@li... Subject: Re: [Playerstage-developers] SF Migration Update Hi all, It's been quite a while since my last progress update, mostly because the 2015 and 2016 have been very busy for me (I got my master's degree, bought a house, and got married within the course of 12 months.) Things have since slowed down for me a little bit, and I'm finally able to dedicate a little more time to the Player project efforts. I'm going to reply inline to note the progress on individual items: On 06/27/2015 01:03 PM, Rich Mattes wrote: > Hi all, > > Quick progress report on the SF -> Github migration effort. > > The Player repository, as well as the Papers and Website repositories, > have been exported from SVN and uploaded to github. There is one snag - > some of the email addresses in the author file were wrong when I > exported the Player code, and I didn't catch it until after I pushed it > to github. Fixing that error means re-writing the git history and force > pushing over top of the exisitng repository. This is not great, but > since the repository hasn't really been advertised yet I'm going to just > push the fixed history and get it over with. Any forked repositories > and clones will have to fetch the new history and do similar. I think > there's only one fork at the moment (Kevin's) so the impact should be > small. If nobody has any issues with this, I'll do it this weekend. > This was done, and I've pushed a couple of updates to the github repo since. The release-3-1-patches branch will be the staging ground for Player-3.1 release. > I checked the bug and patch trackers on Sourceforge, and there aren't > many open issues left for Player. It looks like it's easy enough to > import the issues to github[1]. I'll run the import script and then > triage any remaining issues (there are a few that belong to Stage and > Gazebo that won't make sense in the new Player-only tracker.) > After more thought, I think it's not really worth it to try to import all of the closed SourceForge issues to GitHub. I made new issues for the couple that were open against Player. I can make the ticket trackers read-only, and modify the main page to redirect people to github. > I haven't made much headway on the site/documentation issues, other than > learning how ReadTheDocs and sphinx work. That means there's still a > few ways the site could go: > 1. host on github, combine site and wiki, re-write site using Jekyll > (seems like a blog platform, maybe not a good fit) > 2. host on github, combine site and wiki, re-write site using Doxygen or > sphinx & import generated html > 3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx > 4. host privately, keep site and wiki as-is > 5. host privately, merge site into wiki, host wiki > 6. host privately, re-write site/wiki however we want I spent this morning working on this, and have managed to create a Jekyll site for github pages that can serve as the new project site. I'm still working on pulling in the content from the wiki and original site. Check it out at https://playerproject.github.io/ I think it will be possible to update the SF site to redirect to the new github site, by adding redirect headers to the existing site's headers. I can probably add php to detect which page is being requested, and redirecting to the appropriate new page. > > I do like the idea of combining the site and the wiki, as I always felt > having both was a bit redundant. In the past I was starting to move the > FAQ and tutorials from the static site to the wiki, so that there was > less overlap and so they could be improved by anyone. Unfortunately > re-writing the site will complicate any redirecting from the SF hosting > location. I am leaning towards option 2, but would like to hear if > anyone has any other opinions. I'm going to try to move all of the general information about the project to the player project github site. I'm thinking about using the github wiki for Player to put player-specific documentation (build/install instructions, etc.) and linking them from the main site. I'm also going to put the doxygen docs in the Player gh-pages branch, similar to rtv.github.io/stage. > > Mailing lists are tricky. It's possible to export the mailing SF list > history from mailman. We could start a new pair of mailing lists at > google groups, and there's a hacky way to import the existing history > there[2]. If we go the self-hosting route, we could set up our own > mailman instance and import the entire history. I think google groups > would be easiest. No progress here - mailing lists are still on SF. > > So next steps are: > - Push updated Player history with corrected email addresses Check > - Export SF bug tracker info, import issues to github I'm going to manually copy any open bugs that are left, and close them on SF with a link to GH > - Determine hosting solution for site and mailing list > - Import/Export mailing lists No progress yet > - Merge site & wiki, host combined site In progress > - Announce migration and new site Will do once I'm done importing content to the new website and wiki. Rich ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
|
From: Rich M. <jp...@gm...> - 2017-01-29 20:46:07
|
Hi all, It's been quite a while since my last progress update, mostly because the 2015 and 2016 have been very busy for me (I got my master's degree, bought a house, and got married within the course of 12 months.) Things have since slowed down for me a little bit, and I'm finally able to dedicate a little more time to the Player project efforts. I'm going to reply inline to note the progress on individual items: On 06/27/2015 01:03 PM, Rich Mattes wrote: > Hi all, > > Quick progress report on the SF -> Github migration effort. > > The Player repository, as well as the Papers and Website repositories, > have been exported from SVN and uploaded to github. There is one snag - > some of the email addresses in the author file were wrong when I > exported the Player code, and I didn't catch it until after I pushed it > to github. Fixing that error means re-writing the git history and force > pushing over top of the exisitng repository. This is not great, but > since the repository hasn't really been advertised yet I'm going to just > push the fixed history and get it over with. Any forked repositories > and clones will have to fetch the new history and do similar. I think > there's only one fork at the moment (Kevin's) so the impact should be > small. If nobody has any issues with this, I'll do it this weekend. > This was done, and I've pushed a couple of updates to the github repo since. The release-3-1-patches branch will be the staging ground for Player-3.1 release. > I checked the bug and patch trackers on Sourceforge, and there aren't > many open issues left for Player. It looks like it's easy enough to > import the issues to github[1]. I'll run the import script and then > triage any remaining issues (there are a few that belong to Stage and > Gazebo that won't make sense in the new Player-only tracker.) > After more thought, I think it's not really worth it to try to import all of the closed SourceForge issues to GitHub. I made new issues for the couple that were open against Player. I can make the ticket trackers read-only, and modify the main page to redirect people to github. > I haven't made much headway on the site/documentation issues, other than > learning how ReadTheDocs and sphinx work. That means there's still a > few ways the site could go: > 1. host on github, combine site and wiki, re-write site using Jekyll > (seems like a blog platform, maybe not a good fit) > 2. host on github, combine site and wiki, re-write site using Doxygen or > sphinx & import generated html > 3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx > 4. host privately, keep site and wiki as-is > 5. host privately, merge site into wiki, host wiki > 6. host privately, re-write site/wiki however we want I spent this morning working on this, and have managed to create a Jekyll site for github pages that can serve as the new project site. I'm still working on pulling in the content from the wiki and original site. Check it out at https://playerproject.github.io/ I think it will be possible to update the SF site to redirect to the new github site, by adding redirect headers to the existing site's headers. I can probably add php to detect which page is being requested, and redirecting to the appropriate new page. > > I do like the idea of combining the site and the wiki, as I always felt > having both was a bit redundant. In the past I was starting to move the > FAQ and tutorials from the static site to the wiki, so that there was > less overlap and so they could be improved by anyone. Unfortunately > re-writing the site will complicate any redirecting from the SF hosting > location. I am leaning towards option 2, but would like to hear if > anyone has any other opinions. I'm going to try to move all of the general information about the project to the player project github site. I'm thinking about using the github wiki for Player to put player-specific documentation (build/install instructions, etc.) and linking them from the main site. I'm also going to put the doxygen docs in the Player gh-pages branch, similar to rtv.github.io/stage. > > Mailing lists are tricky. It's possible to export the mailing SF list > history from mailman. We could start a new pair of mailing lists at > google groups, and there's a hacky way to import the existing history > there[2]. If we go the self-hosting route, we could set up our own > mailman instance and import the entire history. I think google groups > would be easiest. No progress here - mailing lists are still on SF. > > So next steps are: > - Push updated Player history with corrected email addresses Check > - Export SF bug tracker info, import issues to github I'm going to manually copy any open bugs that are left, and close them on SF with a link to GH > - Determine hosting solution for site and mailing list > - Import/Export mailing lists No progress yet > - Merge site & wiki, host combined site In progress > - Announce migration and new site Will do once I'm done importing content to the new website and wiki. Rich |
|
From: Toby C. <tco...@pl...> - 2016-11-06 08:17:53
|
This should be the latest code, https://github.com/playerproject/player - Toby On Sat, 5 Nov 2016 at 05:49 Fred Labrosse <ff...@ab...> wrote: > All, > > More than a year later, I'm trying to get the latest player, and I don't > know where from. The last message about that seems to indicate that the > move from SF to github has been done, but I can't find it. Searching > for player on google or github is not very useful! > > Any pointer please? > > Cheers, > > Fred > > PS. So far I have used my SF (svn) version that I carry from computer to > computer, with my mods in, but tried to get a fresh copy with perhaps > some updates. > > On 28/06/15 17:16, Rich Mattes wrote: > > OK it's done, following the instructions at [1]. If you've got a fork of > > the repository, you'll either need to delete and re-fork it, or try to > > sync your fork's history to the new history upstream. And your local > > clones of the repositories will need to be fixed as well. > > > > As far as patches go, pull requests like the one for the swig fixes are > > a good way to submit changes. Bascially, create a branch in your local > > repository for a new feature, and once you're happy push that branch to > > your forked github repository and open a pull request. You can also get > > text diffs using the 'git diff' and 'git format-patch' commands. > > > > I'm pretty sure github also lets you check out repositories through svn > > and interact with them that way, but I've never tried it. > > > > Rich > > > > [1] https://help.github.com/articles/changing-author-info/ > > > >> Hi Rich and all, > >> > >> Great to see movement! > >> > >> I have never really used github and the like (I have stayed with CVS > for very long and then moved to svn and have stayed with it since…). > >> > >> I guess this change means that we will have to create new “working > copies” (probably not the correct term in github world) and merge our mods > into it from the SF working copy? Correct? > >> > >> Then I’ll have to figure out how to create patches in the github world. > >> > >> Cheers, > >> > >> Fred > >> > >>> On 27 Jun 2015, at 18:03, Rich Mattes <jp...@gm...> wrote: > >>> > >>> Hi all, > >>> > >>> Quick progress report on the SF -> Github migration effort. > >>> > >>> The Player repository, as well as the Papers and Website repositories, > >>> have been exported from SVN and uploaded to github. There is one snag > - > >>> some of the email addresses in the author file were wrong when I > >>> exported the Player code, and I didn't catch it until after I pushed it > >>> to github. Fixing that error means re-writing the git history and > force > >>> pushing over top of the exisitng repository. This is not great, but > >>> since the repository hasn't really been advertised yet I'm going to > just > >>> push the fixed history and get it over with. Any forked repositories > >>> and clones will have to fetch the new history and do similar. I think > >>> there's only one fork at the moment (Kevin's) so the impact should be > >>> small. If nobody has any issues with this, I'll do it this weekend. > >>> > >>> I checked the bug and patch trackers on Sourceforge, and there aren't > >>> many open issues left for Player. It looks like it's easy enough to > >>> import the issues to github[1]. I'll run the import script and then > >>> triage any remaining issues (there are a few that belong to Stage and > >>> Gazebo that won't make sense in the new Player-only tracker.) > >>> > >>> I haven't made much headway on the site/documentation issues, other > than > >>> learning how ReadTheDocs and sphinx work. That means there's still a > >>> few ways the site could go: > >>> 1. host on github, combine site and wiki, re-write site using Jekyll > >>> (seems like a blog platform, maybe not a good fit) > >>> 2. host on github, combine site and wiki, re-write site using Doxygen > or > >>> sphinx & import generated html > >>> 3. host on ReadTheDocs, combine site and wiki, re-write site using > sphinx > >>> 4. host privately, keep site and wiki as-is > >>> 5. host privately, merge site into wiki, host wiki > >>> 6. host privately, re-write site/wiki however we want > >>> > >>> I do like the idea of combining the site and the wiki, as I always felt > >>> having both was a bit redundant. In the past I was starting to move > the > >>> FAQ and tutorials from the static site to the wiki, so that there was > >>> less overlap and so they could be improved by anyone. Unfortunately > >>> re-writing the site will complicate any redirecting from the SF hosting > >>> location. I am leaning towards option 2, but would like to hear if > >>> anyone has any other opinions. > >>> > >>> Mailing lists are tricky. It's possible to export the mailing SF list > >>> history from mailman. We could start a new pair of mailing lists at > >>> google groups, and there's a hacky way to import the existing history > >>> there[2]. If we go the self-hosting route, we could set up our own > >>> mailman instance and import the entire history. I think google groups > >>> would be easiest. > >>> > >>> So next steps are: > >>> - Push updated Player history with corrected email addresses > >>> - Export SF bug tracker info, import issues to github > >>> - Determine hosting solution for site and mailing list > >>> - Import/Export mailing lists > >>> - Merge site & wiki, host combined site > >>> - Announce migration and new site > >>> > >>> Rich > >>> > >>> [1] https://github.com/cmungall/gosf2github > >>> [2] https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups > >>> > >>> > ------------------------------------------------------------------------------ > >>> Monitor 25 network devices or servers for free with OpManager! > >>> OpManager is web-based network management software that monitors > >>> network devices and physical & virtual servers, alerts via email & sms > >>> for fault. Monitor 25 devices for free with no restriction. Download > now > >>> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > >>> _______________________________________________ > >>> Playerstage-developers mailing list > >>> Pla...@li... > >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > >> > >> > ------------------------------------------------------------------------------ > >> Monitor 25 network devices or servers for free with OpManager! > >> OpManager is web-based network management software that monitors > >> network devices and physical & virtual servers, alerts via email & sms > >> for fault. Monitor 25 devices for free with no restriction. Download now > >> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > ------------------------------------------------------------------------------ > > Monitor 25 network devices or servers for free with OpManager! > > OpManager is web-based network management software that monitors > > network devices and physical & virtual servers, alerts via email & sms > > for fault. Monitor 25 devices for free with no restriction. Download now > > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > -------------------------------------------------------------------- > Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd > myfyrwyr. > (Arolwg Cenedlaethol y Myfyrwyr 2016) > www.aber.ac.uk > > Top 4 UK university and best in Wales for student satisfaction > (National Student Survey 2016) > www.aber.ac.uk > > > ------------------------------------------------------------------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
|
From: Fred L. <ff...@ab...> - 2016-11-04 16:49:26
|
All, More than a year later, I'm trying to get the latest player, and I don't know where from. The last message about that seems to indicate that the move from SF to github has been done, but I can't find it. Searching for player on google or github is not very useful! Any pointer please? Cheers, Fred PS. So far I have used my SF (svn) version that I carry from computer to computer, with my mods in, but tried to get a fresh copy with perhaps some updates. On 28/06/15 17:16, Rich Mattes wrote: > OK it's done, following the instructions at [1]. If you've got a fork of > the repository, you'll either need to delete and re-fork it, or try to > sync your fork's history to the new history upstream. And your local > clones of the repositories will need to be fixed as well. > > As far as patches go, pull requests like the one for the swig fixes are > a good way to submit changes. Bascially, create a branch in your local > repository for a new feature, and once you're happy push that branch to > your forked github repository and open a pull request. You can also get > text diffs using the 'git diff' and 'git format-patch' commands. > > I'm pretty sure github also lets you check out repositories through svn > and interact with them that way, but I've never tried it. > > Rich > > [1] https://help.github.com/articles/changing-author-info/ > >> Hi Rich and all, >> >> Great to see movement! >> >> I have never really used github and the like (I have stayed with CVS for very long and then moved to svn and have stayed with it since…). >> >> I guess this change means that we will have to create new “working copies” (probably not the correct term in github world) and merge our mods into it from the SF working copy? Correct? >> >> Then I’ll have to figure out how to create patches in the github world. >> >> Cheers, >> >> Fred >> >>> On 27 Jun 2015, at 18:03, Rich Mattes <jp...@gm...> wrote: >>> >>> Hi all, >>> >>> Quick progress report on the SF -> Github migration effort. >>> >>> The Player repository, as well as the Papers and Website repositories, >>> have been exported from SVN and uploaded to github. There is one snag - >>> some of the email addresses in the author file were wrong when I >>> exported the Player code, and I didn't catch it until after I pushed it >>> to github. Fixing that error means re-writing the git history and force >>> pushing over top of the exisitng repository. This is not great, but >>> since the repository hasn't really been advertised yet I'm going to just >>> push the fixed history and get it over with. Any forked repositories >>> and clones will have to fetch the new history and do similar. I think >>> there's only one fork at the moment (Kevin's) so the impact should be >>> small. If nobody has any issues with this, I'll do it this weekend. >>> >>> I checked the bug and patch trackers on Sourceforge, and there aren't >>> many open issues left for Player. It looks like it's easy enough to >>> import the issues to github[1]. I'll run the import script and then >>> triage any remaining issues (there are a few that belong to Stage and >>> Gazebo that won't make sense in the new Player-only tracker.) >>> >>> I haven't made much headway on the site/documentation issues, other than >>> learning how ReadTheDocs and sphinx work. That means there's still a >>> few ways the site could go: >>> 1. host on github, combine site and wiki, re-write site using Jekyll >>> (seems like a blog platform, maybe not a good fit) >>> 2. host on github, combine site and wiki, re-write site using Doxygen or >>> sphinx & import generated html >>> 3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx >>> 4. host privately, keep site and wiki as-is >>> 5. host privately, merge site into wiki, host wiki >>> 6. host privately, re-write site/wiki however we want >>> >>> I do like the idea of combining the site and the wiki, as I always felt >>> having both was a bit redundant. In the past I was starting to move the >>> FAQ and tutorials from the static site to the wiki, so that there was >>> less overlap and so they could be improved by anyone. Unfortunately >>> re-writing the site will complicate any redirecting from the SF hosting >>> location. I am leaning towards option 2, but would like to hear if >>> anyone has any other opinions. >>> >>> Mailing lists are tricky. It's possible to export the mailing SF list >>> history from mailman. We could start a new pair of mailing lists at >>> google groups, and there's a hacky way to import the existing history >>> there[2]. If we go the self-hosting route, we could set up our own >>> mailman instance and import the entire history. I think google groups >>> would be easiest. >>> >>> So next steps are: >>> - Push updated Player history with corrected email addresses >>> - Export SF bug tracker info, import issues to github >>> - Determine hosting solution for site and mailing list >>> - Import/Export mailing lists >>> - Merge site & wiki, host combined site >>> - Announce migration and new site >>> >>> Rich >>> >>> [1] https://github.com/cmungall/gosf2github >>> [2] https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups >>> >>> ------------------------------------------------------------------------------ >>> Monitor 25 network devices or servers for free with OpManager! >>> OpManager is web-based network management software that monitors >>> network devices and physical & virtual servers, alerts via email & sms >>> for fault. Monitor 25 devices for free with no restriction. Download now >>> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o >>> _______________________________________________ >>> Playerstage-developers mailing list >>> Pla...@li... >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >> >> ------------------------------------------------------------------------------ >> Monitor 25 network devices or servers for free with OpManager! >> OpManager is web-based network management software that monitors >> network devices and physical & virtual servers, alerts via email & sms >> for fault. Monitor 25 devices for free with no restriction. Download now >> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > ------------------------------------------------------------------------------ > Monitor 25 network devices or servers for free with OpManager! > OpManager is web-based network management software that monitors > network devices and physical & virtual servers, alerts via email & sms > for fault. Monitor 25 devices for free with no restriction. Download now > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -------------------------------------------------------------------- Un o’r 4 prifysgol uchaf yn y DU a’r orau yng Nghymru am fodlonrwydd myfyrwyr. (Arolwg Cenedlaethol y Myfyrwyr 2016) www.aber.ac.uk Top 4 UK university and best in Wales for student satisfaction (National Student Survey 2016) www.aber.ac.uk |
|
From: Cheuk Ho Y. <chy...@co...> - 2016-06-21 06:46:57
|
Dear Senior developers, Hello, I am a research student who is doing research on swarm robotics system. I started using Stage as an standalone simulator for my algorithm since last few months. I would like to ask is there any way that I can show/log some user-defined data (eg. values in the loss function, states of the robots) in the GUI or a system generated txt. ? I searched through most of the files and seems only a virtual energy value and simulation clock are displayed in the GUI. I am using Stage 4.1.0. If I sent to a wrong mailing list or the answer is already somewhere in the released document, I am sorry and please kindly let me know. Thank you very much Yours sincerely, Ambi Yuen |
|
From: BiggsGeoffrey <geo...@ai...> - 2015-06-28 21:48:45
|
Hi Fred (and anyone else who's new to Git) The Git book is a good place to start. It explains the basic concepts of Git, which are different from SVN, and many common use cases. http://git-scm.com/book Geoff ________________________________________ From: Fred Labrosse <ff...@ab...> Sent: Sunday, 28 June 2015 8:56 p.m. To: pla...@li... Subject: Re: [Playerstage-developers] SF Migration Update Hi Rich and all, Great to see movement! I have never really used github and the like (I have stayed with CVS for very long and then moved to svn and have stayed with it since…). I guess this change means that we will have to create new “working copies” (probably not the correct term in github world) and merge our mods into it from the SF working copy? Correct? Then I’ll have to figure out how to create patches in the github world. Cheers, Fred > On 27 Jun 2015, at 18:03, Rich Mattes <jp...@gm...> wrote: > > Hi all, > > Quick progress report on the SF -> Github migration effort. > > The Player repository, as well as the Papers and Website repositories, > have been exported from SVN and uploaded to github. There is one snag - > some of the email addresses in the author file were wrong when I > exported the Player code, and I didn't catch it until after I pushed it > to github. Fixing that error means re-writing the git history and force > pushing over top of the exisitng repository. This is not great, but > since the repository hasn't really been advertised yet I'm going to just > push the fixed history and get it over with. Any forked repositories > and clones will have to fetch the new history and do similar. I think > there's only one fork at the moment (Kevin's) so the impact should be > small. If nobody has any issues with this, I'll do it this weekend. > > I checked the bug and patch trackers on Sourceforge, and there aren't > many open issues left for Player. It looks like it's easy enough to > import the issues to github[1]. I'll run the import script and then > triage any remaining issues (there are a few that belong to Stage and > Gazebo that won't make sense in the new Player-only tracker.) > > I haven't made much headway on the site/documentation issues, other than > learning how ReadTheDocs and sphinx work. That means there's still a > few ways the site could go: > 1. host on github, combine site and wiki, re-write site using Jekyll > (seems like a blog platform, maybe not a good fit) > 2. host on github, combine site and wiki, re-write site using Doxygen or > sphinx & import generated html > 3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx > 4. host privately, keep site and wiki as-is > 5. host privately, merge site into wiki, host wiki > 6. host privately, re-write site/wiki however we want > > I do like the idea of combining the site and the wiki, as I always felt > having both was a bit redundant. In the past I was starting to move the > FAQ and tutorials from the static site to the wiki, so that there was > less overlap and so they could be improved by anyone. Unfortunately > re-writing the site will complicate any redirecting from the SF hosting > location. I am leaning towards option 2, but would like to hear if > anyone has any other opinions. > > Mailing lists are tricky. It's possible to export the mailing SF list > history from mailman. We could start a new pair of mailing lists at > google groups, and there's a hacky way to import the existing history > there[2]. If we go the self-hosting route, we could set up our own > mailman instance and import the entire history. I think google groups > would be easiest. > > So next steps are: > - Push updated Player history with corrected email addresses > - Export SF bug tracker info, import issues to github > - Determine hosting solution for site and mailing list > - Import/Export mailing lists > - Merge site & wiki, host combined site > - Announce migration and new site > > Rich > > [1] https://github.com/cmungall/gosf2github > [2] https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups > > ------------------------------------------------------------------------------ > Monitor 25 network devices or servers for free with OpManager! > OpManager is web-based network management software that monitors > network devices and physical & virtual servers, alerts via email & sms > for fault. Monitor 25 devices for free with no restriction. Download now > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
|
From: BiggsGeoffrey <geo...@ai...> - 2015-06-28 21:47:36
|
Hi Rich,
Great work on the migration so far.
An option for hosting that isn't in your list is using github's wiki feature. Its page display is very narrow, but it could work.
I like the idea of combining the site and wiki. We could just have a single static landing page done through Jekyll if we want to look fancy, and redirect visitors to the wiki for further information.
Geoff
________________________________________
From: Rich Mattes <jp...@gm...>
Sent: Sunday, 28 June 2015 2:03 a.m.
To: pla...@li...
Subject: [Playerstage-developers] SF Migration Update
Hi all,
Quick progress report on the SF -> Github migration effort.
The Player repository, as well as the Papers and Website repositories,
have been exported from SVN and uploaded to github. There is one snag -
some of the email addresses in the author file were wrong when I
exported the Player code, and I didn't catch it until after I pushed it
to github. Fixing that error means re-writing the git history and force
pushing over top of the exisitng repository. This is not great, but
since the repository hasn't really been advertised yet I'm going to just
push the fixed history and get it over with. Any forked repositories
and clones will have to fetch the new history and do similar. I think
there's only one fork at the moment (Kevin's) so the impact should be
small. If nobody has any issues with this, I'll do it this weekend.
I checked the bug and patch trackers on Sourceforge, and there aren't
many open issues left for Player. It looks like it's easy enough to
import the issues to github[1]. I'll run the import script and then
triage any remaining issues (there are a few that belong to Stage and
Gazebo that won't make sense in the new Player-only tracker.)
I haven't made much headway on the site/documentation issues, other than
learning how ReadTheDocs and sphinx work. That means there's still a
few ways the site could go:
1. host on github, combine site and wiki, re-write site using Jekyll
(seems like a blog platform, maybe not a good fit)
2. host on github, combine site and wiki, re-write site using Doxygen or
sphinx & import generated html
3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx
4. host privately, keep site and wiki as-is
5. host privately, merge site into wiki, host wiki
6. host privately, re-write site/wiki however we want
I do like the idea of combining the site and the wiki, as I always felt
having both was a bit redundant. In the past I was starting to move the
FAQ and tutorials from the static site to the wiki, so that there was
less overlap and so they could be improved by anyone. Unfortunately
re-writing the site will complicate any redirecting from the SF hosting
location. I am leaning towards option 2, but would like to hear if
anyone has any other opinions.
Mailing lists are tricky. It's possible to export the mailing SF list
history from mailman. We could start a new pair of mailing lists at
google groups, and there's a hacky way to import the existing history
there[2]. If we go the self-hosting route, we could set up our own
mailman instance and import the entire history. I think google groups
would be easiest.
So next steps are:
- Push updated Player history with corrected email addresses
- Export SF bug tracker info, import issues to github
- Determine hosting solution for site and mailing list
- Import/Export mailing lists
- Merge site & wiki, host combined site
- Announce migration and new site
Rich
[1] https://github.com/cmungall/gosf2github
[2] https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Playerstage-developers mailing list
Pla...@li...
https://lists.sourceforge.net/lists/listinfo/playerstage-developers
|
|
From: Rich M. <jp...@gm...> - 2015-06-28 16:16:23
|
OK it's done, following the instructions at [1]. If you've got a fork of the repository, you'll either need to delete and re-fork it, or try to sync your fork's history to the new history upstream. And your local clones of the repositories will need to be fixed as well. As far as patches go, pull requests like the one for the swig fixes are a good way to submit changes. Bascially, create a branch in your local repository for a new feature, and once you're happy push that branch to your forked github repository and open a pull request. You can also get text diffs using the 'git diff' and 'git format-patch' commands. I'm pretty sure github also lets you check out repositories through svn and interact with them that way, but I've never tried it. Rich [1] https://help.github.com/articles/changing-author-info/ > Hi Rich and all, > > Great to see movement! > > I have never really used github and the like (I have stayed with CVS for very long and then moved to svn and have stayed with it since…). > > I guess this change means that we will have to create new “working copies” (probably not the correct term in github world) and merge our mods into it from the SF working copy? Correct? > > Then I’ll have to figure out how to create patches in the github world. > > Cheers, > > Fred > >> On 27 Jun 2015, at 18:03, Rich Mattes <jp...@gm...> wrote: >> >> Hi all, >> >> Quick progress report on the SF -> Github migration effort. >> >> The Player repository, as well as the Papers and Website repositories, >> have been exported from SVN and uploaded to github. There is one snag - >> some of the email addresses in the author file were wrong when I >> exported the Player code, and I didn't catch it until after I pushed it >> to github. Fixing that error means re-writing the git history and force >> pushing over top of the exisitng repository. This is not great, but >> since the repository hasn't really been advertised yet I'm going to just >> push the fixed history and get it over with. Any forked repositories >> and clones will have to fetch the new history and do similar. I think >> there's only one fork at the moment (Kevin's) so the impact should be >> small. If nobody has any issues with this, I'll do it this weekend. >> >> I checked the bug and patch trackers on Sourceforge, and there aren't >> many open issues left for Player. It looks like it's easy enough to >> import the issues to github[1]. I'll run the import script and then >> triage any remaining issues (there are a few that belong to Stage and >> Gazebo that won't make sense in the new Player-only tracker.) >> >> I haven't made much headway on the site/documentation issues, other than >> learning how ReadTheDocs and sphinx work. That means there's still a >> few ways the site could go: >> 1. host on github, combine site and wiki, re-write site using Jekyll >> (seems like a blog platform, maybe not a good fit) >> 2. host on github, combine site and wiki, re-write site using Doxygen or >> sphinx & import generated html >> 3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx >> 4. host privately, keep site and wiki as-is >> 5. host privately, merge site into wiki, host wiki >> 6. host privately, re-write site/wiki however we want >> >> I do like the idea of combining the site and the wiki, as I always felt >> having both was a bit redundant. In the past I was starting to move the >> FAQ and tutorials from the static site to the wiki, so that there was >> less overlap and so they could be improved by anyone. Unfortunately >> re-writing the site will complicate any redirecting from the SF hosting >> location. I am leaning towards option 2, but would like to hear if >> anyone has any other opinions. >> >> Mailing lists are tricky. It's possible to export the mailing SF list >> history from mailman. We could start a new pair of mailing lists at >> google groups, and there's a hacky way to import the existing history >> there[2]. If we go the self-hosting route, we could set up our own >> mailman instance and import the entire history. I think google groups >> would be easiest. >> >> So next steps are: >> - Push updated Player history with corrected email addresses >> - Export SF bug tracker info, import issues to github >> - Determine hosting solution for site and mailing list >> - Import/Export mailing lists >> - Merge site & wiki, host combined site >> - Announce migration and new site >> >> Rich >> >> [1] https://github.com/cmungall/gosf2github >> [2] https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups >> >> ------------------------------------------------------------------------------ >> Monitor 25 network devices or servers for free with OpManager! >> OpManager is web-based network management software that monitors >> network devices and physical & virtual servers, alerts via email & sms >> for fault. Monitor 25 devices for free with no restriction. Download now >> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > ------------------------------------------------------------------------------ > Monitor 25 network devices or servers for free with OpManager! > OpManager is web-based network management software that monitors > network devices and physical & virtual servers, alerts via email & sms > for fault. Monitor 25 devices for free with no restriction. Download now > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
|
From: Fred L. <ff...@ab...> - 2015-06-28 12:12:00
|
Hi Rich and all, Great to see movement! I have never really used github and the like (I have stayed with CVS for very long and then moved to svn and have stayed with it since…). I guess this change means that we will have to create new “working copies” (probably not the correct term in github world) and merge our mods into it from the SF working copy? Correct? Then I’ll have to figure out how to create patches in the github world. Cheers, Fred > On 27 Jun 2015, at 18:03, Rich Mattes <jp...@gm...> wrote: > > Hi all, > > Quick progress report on the SF -> Github migration effort. > > The Player repository, as well as the Papers and Website repositories, > have been exported from SVN and uploaded to github. There is one snag - > some of the email addresses in the author file were wrong when I > exported the Player code, and I didn't catch it until after I pushed it > to github. Fixing that error means re-writing the git history and force > pushing over top of the exisitng repository. This is not great, but > since the repository hasn't really been advertised yet I'm going to just > push the fixed history and get it over with. Any forked repositories > and clones will have to fetch the new history and do similar. I think > there's only one fork at the moment (Kevin's) so the impact should be > small. If nobody has any issues with this, I'll do it this weekend. > > I checked the bug and patch trackers on Sourceforge, and there aren't > many open issues left for Player. It looks like it's easy enough to > import the issues to github[1]. I'll run the import script and then > triage any remaining issues (there are a few that belong to Stage and > Gazebo that won't make sense in the new Player-only tracker.) > > I haven't made much headway on the site/documentation issues, other than > learning how ReadTheDocs and sphinx work. That means there's still a > few ways the site could go: > 1. host on github, combine site and wiki, re-write site using Jekyll > (seems like a blog platform, maybe not a good fit) > 2. host on github, combine site and wiki, re-write site using Doxygen or > sphinx & import generated html > 3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx > 4. host privately, keep site and wiki as-is > 5. host privately, merge site into wiki, host wiki > 6. host privately, re-write site/wiki however we want > > I do like the idea of combining the site and the wiki, as I always felt > having both was a bit redundant. In the past I was starting to move the > FAQ and tutorials from the static site to the wiki, so that there was > less overlap and so they could be improved by anyone. Unfortunately > re-writing the site will complicate any redirecting from the SF hosting > location. I am leaning towards option 2, but would like to hear if > anyone has any other opinions. > > Mailing lists are tricky. It's possible to export the mailing SF list > history from mailman. We could start a new pair of mailing lists at > google groups, and there's a hacky way to import the existing history > there[2]. If we go the self-hosting route, we could set up our own > mailman instance and import the entire history. I think google groups > would be easiest. > > So next steps are: > - Push updated Player history with corrected email addresses > - Export SF bug tracker info, import issues to github > - Determine hosting solution for site and mailing list > - Import/Export mailing lists > - Merge site & wiki, host combined site > - Announce migration and new site > > Rich > > [1] https://github.com/cmungall/gosf2github > [2] https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups > > ------------------------------------------------------------------------------ > Monitor 25 network devices or servers for free with OpManager! > OpManager is web-based network management software that monitors > network devices and physical & virtual servers, alerts via email & sms > for fault. Monitor 25 devices for free with no restriction. Download now > http://ad.doubleclick.net/ddm/clk/292181274;119417398;o > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
|
From: Rich M. <jp...@gm...> - 2015-06-27 17:03:10
|
Hi all,
Quick progress report on the SF -> Github migration effort.
The Player repository, as well as the Papers and Website repositories,
have been exported from SVN and uploaded to github. There is one snag -
some of the email addresses in the author file were wrong when I
exported the Player code, and I didn't catch it until after I pushed it
to github. Fixing that error means re-writing the git history and force
pushing over top of the exisitng repository. This is not great, but
since the repository hasn't really been advertised yet I'm going to just
push the fixed history and get it over with. Any forked repositories
and clones will have to fetch the new history and do similar. I think
there's only one fork at the moment (Kevin's) so the impact should be
small. If nobody has any issues with this, I'll do it this weekend.
I checked the bug and patch trackers on Sourceforge, and there aren't
many open issues left for Player. It looks like it's easy enough to
import the issues to github[1]. I'll run the import script and then
triage any remaining issues (there are a few that belong to Stage and
Gazebo that won't make sense in the new Player-only tracker.)
I haven't made much headway on the site/documentation issues, other than
learning how ReadTheDocs and sphinx work. That means there's still a
few ways the site could go:
1. host on github, combine site and wiki, re-write site using Jekyll
(seems like a blog platform, maybe not a good fit)
2. host on github, combine site and wiki, re-write site using Doxygen or
sphinx & import generated html
3. host on ReadTheDocs, combine site and wiki, re-write site using sphinx
4. host privately, keep site and wiki as-is
5. host privately, merge site into wiki, host wiki
6. host privately, re-write site/wiki however we want
I do like the idea of combining the site and the wiki, as I always felt
having both was a bit redundant. In the past I was starting to move the
FAQ and tutorials from the static site to the wiki, so that there was
less overlap and so they could be improved by anyone. Unfortunately
re-writing the site will complicate any redirecting from the SF hosting
location. I am leaning towards option 2, but would like to hear if
anyone has any other opinions.
Mailing lists are tricky. It's possible to export the mailing SF list
history from mailman. We could start a new pair of mailing lists at
google groups, and there's a hacky way to import the existing history
there[2]. If we go the self-hosting route, we could set up our own
mailman instance and import the entire history. I think google groups
would be easiest.
So next steps are:
- Push updated Player history with corrected email addresses
- Export SF bug tracker info, import issues to github
- Determine hosting solution for site and mailing list
- Import/Export mailing lists
- Merge site & wiki, host combined site
- Announce migration and new site
Rich
[1] https://github.com/cmungall/gosf2github
[2] https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups
|
|
From: Reed H. <Ree...@Ad...> - 2015-06-17 18:10:09
|
When you do migrate the website, it would be great if all (or at least the main) pages on the old website redirect or point people to the new one, I'm sure there are lots of extant links to various pages in playerstage.sf.net, people will need to find those as well as other resources currently still on sourceforge like a new mailing list if there will be one, etc. Thanks for all your work in maintenance, Rich! Reed -----Original Message----- From: Rich Mattes [mailto:jp...@gm...] Sent: Wednesday, June 10, 2015 8:35 PM To: pla...@li... Subject: Re: [Playerstage-developers] Is player dead? Hi all, First, yes, I am still maintaining Player and I'm happy to accept patches and field bug reports. It's not under active development anymore, but it's not dead by any means. I've been chipping away at things here and there, like updating drivers to support new library versions and updating the xdr and interface generation scripts to work with python 3. I'm glad this thread has popped up, as I've been thinking about the sourceforge hosting situation for the past few days, and addressing it has been quickly moving up my to-do list. About a year or two ago I worked out the proper git-svn incantation and username/email address mappings to export the entire Player svn repository history into git. I'll try to dig that up again and see if I can get the tree and the history into git locally. Github and Bitbucket are both good choices for a new host, though I lean towards github because it's a lot more popular. My gameplan is to set up a github organization called "playerproject" to host the code under, and create a "player" repository underneath for the Player code. Once I push the git tree, I'll add whichever of you would like to be part of the new github org and look at migrating the issues, wiki, website, api docs, etc. from sf and tagging a 3.1 release under the new infrastructure. I don't have a lot of time for the rest of this month, but I think I can at least get the code moved, and worry about the rest once I get some more free time. Rich On 06/10/2015 07:05 PM, BiggsGeoffrey wrote: > I think that they already have melted down. The recent incident with > SF taking over the GIMP Windows project and bundling adware in the > installer was not an isolated incident. > > > Github would seem to be the logical choice at the moment, but I think > that any migration destination should be driven by Rich's needs, to > ensure he can maintain it easily. > > > Geoff > > > ---------------------------------------------------------------------- > -- > *From:* Richard Vaughan <va...@sf...> > *Sent:* Thursday, 11 June 2015 3:04 a.m. > *To:* pla...@li... > *Subject:* Re: [Playerstage-developers] Is player dead? > Seconding Brian's answer. Player and Stage are mature and in > maintenance mode. Rich is accepting patches that fix bugs, etc. but > may not respond as quickly as in past years. The code remains available and always will. > > By the way, we might want to migrate Player away from SourceForge > before they melt down completely. > > Richard/ > > > On Wed, Jun 10, 2015 at 10:35 AM, Brian Gerkey <br...@ge... > <mailto:br...@ge...>> wrote: > > hi Fred, > > It's awesome to hear that you're still using Player. We put a lot of > effort into that tool for many years. > > It's fair to say that Player is no longer under active development, > but that doesn't mean that it's dead. I handed over responsibility > for Player to the very capable Rich Mattes several years ago, when I > turned my attention to ROS. I think that Rich is still applying > patches. Looks like this is the place to submit them: > http://sourceforge.net/p/playerstage/patches/ > > brian. > > On Wed, Jun 10, 2015 at 8:32 AM, Fred Labrosse <ff...@ab... > <mailto:ff...@ab...>> wrote: > > All, > > > > Sorry for the blunt question, but do I sense that player is dying? > > > > I'm asking because I am still using it, but see very little traffic on either mailing list and very few commits made to the svn repository. I have a few diffs to submit that have to do with ptz interfaces and the sonyevid30 driver and I was wondering if there was any point in submitting them. > > > > Player has been very useful to me for many years, and I would hate seeing it disappear, especially since changing to something else, such as ROS, would be quite some work for me to port some of our player code to the new system. > > > > Any views on that? > > > > Cheers, > > > > Fred > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Playerstage-developers mailing list > >Pla...@li... > <mailto:Pla...@li...> > > >https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > <mailto:Pla...@li...> > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > ---------------------------------------------------------------------- > -------- > > > > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > ------------------------------------------------------------------------------ _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
|
From: Rich M. <jp...@gm...> - 2015-06-17 01:03:01
|
Hi, Currently there's two places where tutorial-like material lives. The first place is the tutorials in the Player source that were part of the Doxygen documentation[1]. Keeping the tutorials in the source tree didn't seem like the greatest idea though, so a few years back I started trying to migrate all of the documentation to the Player wiki[2]. There's a good amount of use-case oriented tutorial material there, plus links to outside tutorial material (including Jenny's manual.) I think the wiki is a reasonable place to put tutorials like this. The ROS guys do the same thing[3], though there's a lot of other projects taking different approaches[4][5] That being said, the tutorial is hosted on Sourceforge's project hosting, which we're thinking about migrating away from. We could keep the wiki if we use a third-party web host. We can also use Github's project site hosting, which is HTML-only (no fancy wikis or CMSs), or we can use the github project wikis, which I don't like too much but they're git repositories and support all the newfangled markdown languages that people use these days. I lean towards trying to keep the wiki alive and using that, but keeping it spam-free on an independent host may be a lot of work. Other than that, I think maybe setting up a "tutorials" repository under playerproject and finding out how to get it published somewhere like gazebo has done seems like a good plan, but I don't have any idea how to pull that off without more research. Rich [1] http://playerstage.sourceforge.net/doc/Player-svn/player/group__tutorials.html [2] http://playerstage.sourceforge.net/wiki/Tutorials [3] http://wiki.ros.org/ROS/Tutorials [4] http://gazebosim.org/tutorials?tut=tutorial_contrib&cat=development [5] http://mrpt.org/tutorials/programming/ On 06/16/2015 04:08 PM, Rashad M wrote: > > > On Tue, Jun 16, 2015 at 6:53 PM, Dr. Kevin Nickels <kni...@tr... > <mailto:kni...@tr...>> wrote: > > +1 on github for the code. > > I'm interested in the documentation discussion - I've been slowly > updating Jenny Owen's tutorial (with her till she got a "real job"). > > I found that LaTeX isn't the best for collaboration (i.e. I can't > have any of my undergrad research students edit it directly), so > we've been putting it into github markdown, now I'm wondering if > that was the best choice :) > > > If you are moving out of latex, I would recommend RST (ReStructured > Text). There is a lot of good things with rst such as using sphinx docs, > convert to latex/pdf/ and more. > > you can also host them on readthedocs.org <http://readthedocs.org> > > Anyway it is upto the devs, just my +1 for rst > > > It's now at https://github.com/NickelsLab/Player-Stage-Manual, if > anyone wants to start picking at it. The python chapters are not > complete, but all the stuff in Version 4 of the manual (which uses > player-3.0.2 and stage-4.1.1) is all there. My current student is > past the player/stage learning phase and is into application > research - so this is now a spare-time project. As Rich says, I'll > get to it as I have time :) > > --kn > |
|
From: Rashad M <moh...@gm...> - 2015-06-16 20:09:23
|
On Tue, Jun 16, 2015 at 6:53 PM, Dr. Kevin Nickels <kni...@tr...> wrote: > +1 on github for the code. > > I'm interested in the documentation discussion - I've been slowly updating > Jenny Owen's tutorial (with her till she got a "real job"). > > I found that LaTeX isn't the best for collaboration (i.e. I can't have any > of my undergrad research students edit it directly), so we've been putting > it into github markdown, now I'm wondering if that was the best choice :) > If you are moving out of latex, I would recommend RST (ReStructured Text). There is a lot of good things with rst such as using sphinx docs, convert to latex/pdf/ and more. you can also host them on readthedocs.org Anyway it is upto the devs, just my +1 for rst > > It's now at https://github.com/NickelsLab/Player-Stage-Manual, if anyone > wants to start picking at it. The python chapters are not complete, but > all the stuff in Version 4 of the manual (which uses player-3.0.2 and > stage-4.1.1) is all there. My current student is past the player/stage > learning phase and is into application research - so this is now a > spare-time project. As Rich says, I'll get to it as I have time :) > > --kn > > On Wed, Jun 10, 2015 at 10:39 PM, Rich Mattes <jp...@gm...> wrote: > >> Alright I got the Player code imported and invited a few people to the >> new github organization. I will grab the "www" and "papers" folders out >> of svn and set up repositories under playerproject for each of them. >> >> Github will let us host a page at playerproject.github.io, but it won't >> let us use php. I can restructure the playerstage.sf.net site to be >> flat html instead of using php, which wouldn't be too hard. I can also >> use some space on my personal webserver to host the site, which will let >> us not have to mess with the site, and will let us import and keep >> running mediawiki with all the wiki spam that entails. I think we can >> worry about that later though. >> >> I have noticed a lot of people using readthedocs.org as well, and also >> have no idea how that works. I'll look into that for the doxygen >> documentation. >> >> Rich >> >> On 06/10/2015 10:21 PM, BiggsGeoffrey wrote: >> > An excellent plan, Rich. >> > >> > I agree that the code is the priority. For the website, etc., they will >> still be usable from SF until SF decides to coopt the project. What about >> putting the website and so on in a branch for now until you have time to >> look at them? >> > >> > One possibly for the API docs is readthedocs.org. I have absolutely no >> idea how they operate, but I seem to be increasingly directed there for >> documentation. >> > >> > Geoff >> > ________________________________________ >> > From: Brian Gerkey <br...@ge...> >> > Sent: Thursday, 11 June 2015 10:08 a.m. >> > To: pla...@li... >> > Subject: Re: [Playerstage-developers] Is player dead? >> > >> > Ditto, +1 to that plan. >> > >> > On Wed, Jun 10, 2015 at 6:05 PM, Richard Vaughan <va...@sf...> >> wrote: >> >> Thanks Rich. Github makes sense to me too. Thanks for working on this. >> >> >> >> R/ >> >> >> >> On Wed, Jun 10, 2015 at 5:35 PM, Rich Mattes <jp...@gm...> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> First, yes, I am still maintaining Player and I'm happy to accept >> >>> patches and field bug reports. It's not under active development >> >>> anymore, but it's not dead by any means. I've been chipping away at >> >>> things here and there, like updating drivers to support new library >> >>> versions and updating the xdr and interface generation scripts to work >> >>> with python 3. >> >>> >> >>> I'm glad this thread has popped up, as I've been thinking about the >> >>> sourceforge hosting situation for the past few days, and addressing >> it >> >>> has been quickly moving up my to-do list. About a year or two ago I >> >>> worked out the proper git-svn incantation and username/email address >> >>> mappings to export the entire Player svn repository history into git. >> >>> I'll try to dig that up again and see if I can get the tree and the >> >>> history into git locally. >> >>> >> >>> Github and Bitbucket are both good choices for a new host, though I >> lean >> >>> towards github because it's a lot more popular. My gameplan is to set >> >>> up a github organization called "playerproject" to host the code >> under, >> >>> and create a "player" repository underneath for the Player code. >> Once I >> >>> push the git tree, I'll add whichever of you would like to be part of >> >>> the new github org and look at migrating the issues, wiki, website, >> api >> >>> docs, etc. from sf and tagging a 3.1 release under the new >> >>> infrastructure. I don't have a lot of time for the rest of this >> month, >> >>> but I think I can at least get the code moved, and worry about the >> rest >> >>> once I get some more free time. >> >>> >> >>> Rich >> >>> >> >>> On 06/10/2015 07:05 PM, BiggsGeoffrey wrote: >> >>>> I think that they already have melted down. The recent incident with >> SF >> >>>> taking over the GIMP Windows project and bundling adware in the >> >>>> installer was not an isolated incident. >> >>>> >> >>>> >> >>>> Github would seem to be the logical choice at the moment, but I think >> >>>> that any migration destination should be driven by Rich's needs, to >> >>>> ensure he can maintain it easily. >> >>>> >> >>>> >> >>>> Geoff >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------ >> >>>> *From:* Richard Vaughan <va...@sf...> >> >>>> *Sent:* Thursday, 11 June 2015 3:04 a.m. >> >>>> *To:* pla...@li... >> >>>> *Subject:* Re: [Playerstage-developers] Is player dead? >> >>>> Seconding Brian's answer. Player and Stage are mature and in >> maintenance >> >>>> mode. Rich is accepting patches that fix bugs, etc. but may not >> respond >> >>>> as quickly as in past years. The code remains available and always >> will. >> >>>> >> >>>> By the way, we might want to migrate Player away from SourceForge >> before >> >>>> they melt down completely. >> >>>> >> >>>> Richard/ >> >>>> >> >>>> >> >>>> On Wed, Jun 10, 2015 at 10:35 AM, Brian Gerkey <br...@ge... >> >>>> <mailto:br...@ge...>> wrote: >> >>>> >> >>>> hi Fred, >> >>>> >> >>>> It's awesome to hear that you're still using Player. We put a >> lot >> >>>> of >> >>>> effort into that tool for many years. >> >>>> >> >>>> It's fair to say that Player is no longer under active >> development, >> >>>> but that doesn't mean that it's dead. I handed over >> responsibility >> >>>> for Player to the very capable Rich Mattes several years ago, >> when I >> >>>> turned my attention to ROS. I think that Rich is still applying >> >>>> patches. Looks like this is the place to submit them: >> >>>> http://sourceforge.net/p/playerstage/patches/ >> >>>> >> >>>> brian. >> >>>> >> >>>> On Wed, Jun 10, 2015 at 8:32 AM, Fred Labrosse <ff...@ab... >> >>>> <mailto:ff...@ab...>> wrote: >> >>>> > All, >> >>>> > >> >>>> > Sorry for the blunt question, but do I sense that player is >> dying? >> >>>> > >> >>>> > I’m asking because I am still using it, but see very little >> >>>> traffic on either mailing list and very few commits made to the svn >> >>>> repository. I have a few diffs to submit that have to do with ptz >> >>>> interfaces and the sonyevid30 driver and I was wondering if there >> was any >> >>>> point in submitting them. >> >>>> > >> >>>> > Player has been very useful to me for many years, and I would >> hate >> >>>> seeing it disappear, especially since changing to something else, >> such as >> >>>> ROS, would be quite some work for me to port some of our player code >> to the >> >>>> new system. >> >>>> > >> >>>> > Any views on that? >> >>>> > >> >>>> > Cheers, >> >>>> > >> >>>> > Fred >> >>>> > >> >>>> > >> >>>> > >> >>>> >> ------------------------------------------------------------------------------ >> >>>> > _______________________________________________ >> >>>> > Playerstage-developers mailing list >> >>>> >Pla...@li... >> >>>> <mailto:Pla...@li...> >> >>>> > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> _______________________________________________ >> >>>> Playerstage-developers mailing list >> >>>> Pla...@li... >> >>>> <mailto:Pla...@li...> >> >>>> >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Playerstage-developers mailing list >> >>>> Pla...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >>>> >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> _______________________________________________ >> >>> Playerstage-developers mailing list >> >>> Pla...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> Playerstage-developers mailing list >> >> Pla...@li... >> >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >> >> > >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Playerstage-developers mailing list >> > Pla...@li... >> > https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > >> > >> ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Playerstage-developers mailing list >> > Pla...@li... >> > https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > > > -- > Kevin Nickels <kni...@tr...> > http://www.trinity.edu/knickels 210-999-7543 > Associate Professor, Engineering Science, Trinity University > Center for Sciences and Innovation (CSI), Rm 470Q, San Antonio TX > 78212-7200 > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > -- Regards, Rashad |
|
From: Dr. K. N. <kni...@tr...> - 2015-06-16 16:53:51
|
+1 on github for the code. I'm interested in the documentation discussion - I've been slowly updating Jenny Owen's tutorial (with her till she got a "real job"). I found that LaTeX isn't the best for collaboration (i.e. I can't have any of my undergrad research students edit it directly), so we've been putting it into github markdown, now I'm wondering if that was the best choice :) It's now at https://github.com/NickelsLab/Player-Stage-Manual, if anyone wants to start picking at it. The python chapters are not complete, but all the stuff in Version 4 of the manual (which uses player-3.0.2 and stage-4.1.1) is all there. My current student is past the player/stage learning phase and is into application research - so this is now a spare-time project. As Rich says, I'll get to it as I have time :) --kn On Wed, Jun 10, 2015 at 10:39 PM, Rich Mattes <jp...@gm...> wrote: > Alright I got the Player code imported and invited a few people to the > new github organization. I will grab the "www" and "papers" folders out > of svn and set up repositories under playerproject for each of them. > > Github will let us host a page at playerproject.github.io, but it won't > let us use php. I can restructure the playerstage.sf.net site to be > flat html instead of using php, which wouldn't be too hard. I can also > use some space on my personal webserver to host the site, which will let > us not have to mess with the site, and will let us import and keep > running mediawiki with all the wiki spam that entails. I think we can > worry about that later though. > > I have noticed a lot of people using readthedocs.org as well, and also > have no idea how that works. I'll look into that for the doxygen > documentation. > > Rich > > On 06/10/2015 10:21 PM, BiggsGeoffrey wrote: > > An excellent plan, Rich. > > > > I agree that the code is the priority. For the website, etc., they will > still be usable from SF until SF decides to coopt the project. What about > putting the website and so on in a branch for now until you have time to > look at them? > > > > One possibly for the API docs is readthedocs.org. I have absolutely no > idea how they operate, but I seem to be increasingly directed there for > documentation. > > > > Geoff > > ________________________________________ > > From: Brian Gerkey <br...@ge...> > > Sent: Thursday, 11 June 2015 10:08 a.m. > > To: pla...@li... > > Subject: Re: [Playerstage-developers] Is player dead? > > > > Ditto, +1 to that plan. > > > > On Wed, Jun 10, 2015 at 6:05 PM, Richard Vaughan <va...@sf...> wrote: > >> Thanks Rich. Github makes sense to me too. Thanks for working on this. > >> > >> R/ > >> > >> On Wed, Jun 10, 2015 at 5:35 PM, Rich Mattes <jp...@gm...> wrote: > >>> > >>> Hi all, > >>> > >>> First, yes, I am still maintaining Player and I'm happy to accept > >>> patches and field bug reports. It's not under active development > >>> anymore, but it's not dead by any means. I've been chipping away at > >>> things here and there, like updating drivers to support new library > >>> versions and updating the xdr and interface generation scripts to work > >>> with python 3. > >>> > >>> I'm glad this thread has popped up, as I've been thinking about the > >>> sourceforge hosting situation for the past few days, and addressing it > >>> has been quickly moving up my to-do list. About a year or two ago I > >>> worked out the proper git-svn incantation and username/email address > >>> mappings to export the entire Player svn repository history into git. > >>> I'll try to dig that up again and see if I can get the tree and the > >>> history into git locally. > >>> > >>> Github and Bitbucket are both good choices for a new host, though I > lean > >>> towards github because it's a lot more popular. My gameplan is to set > >>> up a github organization called "playerproject" to host the code under, > >>> and create a "player" repository underneath for the Player code. Once > I > >>> push the git tree, I'll add whichever of you would like to be part of > >>> the new github org and look at migrating the issues, wiki, website, api > >>> docs, etc. from sf and tagging a 3.1 release under the new > >>> infrastructure. I don't have a lot of time for the rest of this month, > >>> but I think I can at least get the code moved, and worry about the rest > >>> once I get some more free time. > >>> > >>> Rich > >>> > >>> On 06/10/2015 07:05 PM, BiggsGeoffrey wrote: > >>>> I think that they already have melted down. The recent incident with > SF > >>>> taking over the GIMP Windows project and bundling adware in the > >>>> installer was not an isolated incident. > >>>> > >>>> > >>>> Github would seem to be the logical choice at the moment, but I think > >>>> that any migration destination should be driven by Rich's needs, to > >>>> ensure he can maintain it easily. > >>>> > >>>> > >>>> Geoff > >>>> > >>>> > >>>> > ------------------------------------------------------------------------ > >>>> *From:* Richard Vaughan <va...@sf...> > >>>> *Sent:* Thursday, 11 June 2015 3:04 a.m. > >>>> *To:* pla...@li... > >>>> *Subject:* Re: [Playerstage-developers] Is player dead? > >>>> Seconding Brian's answer. Player and Stage are mature and in > maintenance > >>>> mode. Rich is accepting patches that fix bugs, etc. but may not > respond > >>>> as quickly as in past years. The code remains available and always > will. > >>>> > >>>> By the way, we might want to migrate Player away from SourceForge > before > >>>> they melt down completely. > >>>> > >>>> Richard/ > >>>> > >>>> > >>>> On Wed, Jun 10, 2015 at 10:35 AM, Brian Gerkey <br...@ge... > >>>> <mailto:br...@ge...>> wrote: > >>>> > >>>> hi Fred, > >>>> > >>>> It's awesome to hear that you're still using Player. We put a > lot > >>>> of > >>>> effort into that tool for many years. > >>>> > >>>> It's fair to say that Player is no longer under active > development, > >>>> but that doesn't mean that it's dead. I handed over > responsibility > >>>> for Player to the very capable Rich Mattes several years ago, > when I > >>>> turned my attention to ROS. I think that Rich is still applying > >>>> patches. Looks like this is the place to submit them: > >>>> http://sourceforge.net/p/playerstage/patches/ > >>>> > >>>> brian. > >>>> > >>>> On Wed, Jun 10, 2015 at 8:32 AM, Fred Labrosse <ff...@ab... > >>>> <mailto:ff...@ab...>> wrote: > >>>> > All, > >>>> > > >>>> > Sorry for the blunt question, but do I sense that player is > dying? > >>>> > > >>>> > I’m asking because I am still using it, but see very little > >>>> traffic on either mailing list and very few commits made to the svn > >>>> repository. I have a few diffs to submit that have to do with ptz > >>>> interfaces and the sonyevid30 driver and I was wondering if there > was any > >>>> point in submitting them. > >>>> > > >>>> > Player has been very useful to me for many years, and I would > hate > >>>> seeing it disappear, especially since changing to something else, > such as > >>>> ROS, would be quite some work for me to port some of our player code > to the > >>>> new system. > >>>> > > >>>> > Any views on that? > >>>> > > >>>> > Cheers, > >>>> > > >>>> > Fred > >>>> > > >>>> > > >>>> > > >>>> > ------------------------------------------------------------------------------ > >>>> > _______________________________________________ > >>>> > Playerstage-developers mailing list > >>>> >Pla...@li... > >>>> <mailto:Pla...@li...> > >>>> > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> Playerstage-developers mailing list > >>>> Pla...@li... > >>>> <mailto:Pla...@li...> > >>>> > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Playerstage-developers mailing list > >>>> Pla...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Playerstage-developers mailing list > >>> Pla...@li... > >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Kevin Nickels <kni...@tr...> http://www.trinity.edu/knickels 210-999-7543 Associate Professor, Engineering Science, Trinity University Center for Sciences and Innovation (CSI), Rm 470Q, San Antonio TX 78212-7200 |
|
From: Rich M. <jp...@gm...> - 2015-06-11 17:35:21
|
Hi Fred, Great! Please submit them through the new github location: https://github.com/playerproject/player You can post patches to the issue tracker or fork and make pull requests, whichever you prefer. I have added an issue to track the boost.signals2 migration at https://github.com/playerproject/player/issues/1. I can work on porting playerc++ to use the new API and get rid of the deprecation warnings. Rich On Thu, Jun 11, 2015 at 11:52 AM, Fred Labrosse <ff...@ab...> wrote: > Hi Brian, > > Thank you for these encouraging words, and thank you Rich for the work. I > am glad to see that it is still going. > > I will be submitting a few patches/drivers, after I have tested them more. > > I recently noted that compiling against player now throws loads of warnings > about boost signals that need to be converted to signals2. Is that > something that will be done? > > Cheers, > > Fred > > > On Wednesday 10 June 2015 10:35:25 Brian Gerkey wrote: > > hi Fred, > > > > It's awesome to hear that you're still using Player. We put a lot of > > effort into that tool for many years. > > > > It's fair to say that Player is no longer under active development, > > but that doesn't mean that it's dead. I handed over responsibility > > for Player to the very capable Rich Mattes several years ago, when I > > turned my attention to ROS. I think that Rich is still applying > > patches. Looks like this is the place to submit them: > > http://sourceforge.net/p/playerstage/patches/ > > > > brian. > > > > On Wed, Jun 10, 2015 at 8:32 AM, Fred Labrosse <ff...@ab...> wrote: > > > All, > > > > > > Sorry for the blunt question, but do I sense that player is dying? > > > > > > I’m asking because I am still using it, but see very little traffic on > > > either mailing list and very few commits made to the svn repository. > > > I have a few diffs to submit that have to do with ptz interfaces and > > > the sonyevid30 driver and I was wondering if there was any point in > > > submitting them. > > > > > > Player has been very useful to me for many years, and I would hate > > > seeing it disappear, especially since changing to something else, such > > > as ROS, would be quite some work for me to port some of our player > > > code to the new system. > > > > > > Any views on that? > > > > > > Cheers, > > > > > > Fred > > > > > > > > > ----------------------------------------------------------------------- > > > ------- _______________________________________________ > > > Playerstage-developers mailing list > > > Pla...@li... > > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > ------------------------------------------------------------------------- > > ----- _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
|
From: Fred L. <ff...@ab...> - 2015-06-11 15:52:21
|
Hi Brian, Thank you for these encouraging words, and thank you Rich for the work. I am glad to see that it is still going. I will be submitting a few patches/drivers, after I have tested them more. I recently noted that compiling against player now throws loads of warnings about boost signals that need to be converted to signals2. Is that something that will be done? Cheers, Fred On Wednesday 10 June 2015 10:35:25 Brian Gerkey wrote: > hi Fred, > > It's awesome to hear that you're still using Player. We put a lot of > effort into that tool for many years. > > It's fair to say that Player is no longer under active development, > but that doesn't mean that it's dead. I handed over responsibility > for Player to the very capable Rich Mattes several years ago, when I > turned my attention to ROS. I think that Rich is still applying > patches. Looks like this is the place to submit them: > http://sourceforge.net/p/playerstage/patches/ > > brian. > > On Wed, Jun 10, 2015 at 8:32 AM, Fred Labrosse <ff...@ab...> wrote: > > All, > > > > Sorry for the blunt question, but do I sense that player is dying? > > > > I’m asking because I am still using it, but see very little traffic on > > either mailing list and very few commits made to the svn repository. > > I have a few diffs to submit that have to do with ptz interfaces and > > the sonyevid30 driver and I was wondering if there was any point in > > submitting them. > > > > Player has been very useful to me for many years, and I would hate > > seeing it disappear, especially since changing to something else, such > > as ROS, would be quite some work for me to port some of our player > > code to the new system. > > > > Any views on that? > > > > Cheers, > > > > Fred > > > > > > ----------------------------------------------------------------------- > > ------- _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > ------------------------------------------------------------------------- > ----- _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
|
From: Rashad M <moh...@gm...> - 2015-06-11 07:31:00
|
+1. A github org is much appreciated. Looking into sourceforge pageonly to see inactivity is unpleasant On Thu, Jun 11, 2015 at 5:39 AM, Rich Mattes <jp...@gm...> wrote: > Alright I got the Player code imported and invited a few people to the > new github organization. I will grab the "www" and "papers" folders out > of svn and set up repositories under playerproject for each of them. > > Github will let us host a page at playerproject.github.io, but it won't > let us use php. I can restructure the playerstage.sf.net site to be > flat html instead of using php, which wouldn't be too hard. I can also > use some space on my personal webserver to host the site, which will let > us not have to mess with the site, and will let us import and keep > running mediawiki with all the wiki spam that entails. I think we can > worry about that later though. > > I have noticed a lot of people using readthedocs.org as well, and also > have no idea how that works. I'll look into that for the doxygen > documentation. > > Rich > > On 06/10/2015 10:21 PM, BiggsGeoffrey wrote: > > An excellent plan, Rich. > > > > I agree that the code is the priority. For the website, etc., they will > still be usable from SF until SF decides to coopt the project. What about > putting the website and so on in a branch for now until you have time to > look at them? > > > > One possibly for the API docs is readthedocs.org. I have absolutely no > idea how they operate, but I seem to be increasingly directed there for > documentation. > > > > Geoff > > ________________________________________ > > From: Brian Gerkey <br...@ge...> > > Sent: Thursday, 11 June 2015 10:08 a.m. > > To: pla...@li... > > Subject: Re: [Playerstage-developers] Is player dead? > > > > Ditto, +1 to that plan. > > > > On Wed, Jun 10, 2015 at 6:05 PM, Richard Vaughan <va...@sf...> wrote: > >> Thanks Rich. Github makes sense to me too. Thanks for working on this. > >> > >> R/ > >> > >> On Wed, Jun 10, 2015 at 5:35 PM, Rich Mattes <jp...@gm...> wrote: > >>> > >>> Hi all, > >>> > >>> First, yes, I am still maintaining Player and I'm happy to accept > >>> patches and field bug reports. It's not under active development > >>> anymore, but it's not dead by any means. I've been chipping away at > >>> things here and there, like updating drivers to support new library > >>> versions and updating the xdr and interface generation scripts to work > >>> with python 3. > >>> > >>> I'm glad this thread has popped up, as I've been thinking about the > >>> sourceforge hosting situation for the past few days, and addressing it > >>> has been quickly moving up my to-do list. About a year or two ago I > >>> worked out the proper git-svn incantation and username/email address > >>> mappings to export the entire Player svn repository history into git. > >>> I'll try to dig that up again and see if I can get the tree and the > >>> history into git locally. > >>> > >>> Github and Bitbucket are both good choices for a new host, though I > lean > >>> towards github because it's a lot more popular. My gameplan is to set > >>> up a github organization called "playerproject" to host the code under, > >>> and create a "player" repository underneath for the Player code. Once > I > >>> push the git tree, I'll add whichever of you would like to be part of > >>> the new github org and look at migrating the issues, wiki, website, api > >>> docs, etc. from sf and tagging a 3.1 release under the new > >>> infrastructure. I don't have a lot of time for the rest of this month, > >>> but I think I can at least get the code moved, and worry about the rest > >>> once I get some more free time. > >>> > >>> Rich > >>> > >>> On 06/10/2015 07:05 PM, BiggsGeoffrey wrote: > >>>> I think that they already have melted down. The recent incident with > SF > >>>> taking over the GIMP Windows project and bundling adware in the > >>>> installer was not an isolated incident. > >>>> > >>>> > >>>> Github would seem to be the logical choice at the moment, but I think > >>>> that any migration destination should be driven by Rich's needs, to > >>>> ensure he can maintain it easily. > >>>> > >>>> > >>>> Geoff > >>>> > >>>> > >>>> > ------------------------------------------------------------------------ > >>>> *From:* Richard Vaughan <va...@sf...> > >>>> *Sent:* Thursday, 11 June 2015 3:04 a.m. > >>>> *To:* pla...@li... > >>>> *Subject:* Re: [Playerstage-developers] Is player dead? > >>>> Seconding Brian's answer. Player and Stage are mature and in > maintenance > >>>> mode. Rich is accepting patches that fix bugs, etc. but may not > respond > >>>> as quickly as in past years. The code remains available and always > will. > >>>> > >>>> By the way, we might want to migrate Player away from SourceForge > before > >>>> they melt down completely. > >>>> > >>>> Richard/ > >>>> > >>>> > >>>> On Wed, Jun 10, 2015 at 10:35 AM, Brian Gerkey <br...@ge... > >>>> <mailto:br...@ge...>> wrote: > >>>> > >>>> hi Fred, > >>>> > >>>> It's awesome to hear that you're still using Player. We put a > lot > >>>> of > >>>> effort into that tool for many years. > >>>> > >>>> It's fair to say that Player is no longer under active > development, > >>>> but that doesn't mean that it's dead. I handed over > responsibility > >>>> for Player to the very capable Rich Mattes several years ago, > when I > >>>> turned my attention to ROS. I think that Rich is still applying > >>>> patches. Looks like this is the place to submit them: > >>>> http://sourceforge.net/p/playerstage/patches/ > >>>> > >>>> brian. > >>>> > >>>> On Wed, Jun 10, 2015 at 8:32 AM, Fred Labrosse <ff...@ab... > >>>> <mailto:ff...@ab...>> wrote: > >>>> > All, > >>>> > > >>>> > Sorry for the blunt question, but do I sense that player is > dying? > >>>> > > >>>> > I’m asking because I am still using it, but see very little > >>>> traffic on either mailing list and very few commits made to the svn > >>>> repository. I have a few diffs to submit that have to do with ptz > >>>> interfaces and the sonyevid30 driver and I was wondering if there > was any > >>>> point in submitting them. > >>>> > > >>>> > Player has been very useful to me for many years, and I would > hate > >>>> seeing it disappear, especially since changing to something else, > such as > >>>> ROS, would be quite some work for me to port some of our player code > to the > >>>> new system. > >>>> > > >>>> > Any views on that? > >>>> > > >>>> > Cheers, > >>>> > > >>>> > Fred > >>>> > > >>>> > > >>>> > > >>>> > ------------------------------------------------------------------------------ > >>>> > _______________________________________________ > >>>> > Playerstage-developers mailing list > >>>> >Pla...@li... > >>>> <mailto:Pla...@li...> > >>>> > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> Playerstage-developers mailing list > >>>> Pla...@li... > >>>> <mailto:Pla...@li...> > >>>> > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Playerstage-developers mailing list > >>>> Pla...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >>>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Playerstage-developers mailing list > >>> Pla...@li... > >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Playerstage-developers mailing list > >> Pla...@li... > >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers > >> > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Playerstage-developers mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > -- Regards, Rashad |
|
From: Rich M. <jp...@gm...> - 2015-06-11 03:39:25
|
Alright I got the Player code imported and invited a few people to the new github organization. I will grab the "www" and "papers" folders out of svn and set up repositories under playerproject for each of them. Github will let us host a page at playerproject.github.io, but it won't let us use php. I can restructure the playerstage.sf.net site to be flat html instead of using php, which wouldn't be too hard. I can also use some space on my personal webserver to host the site, which will let us not have to mess with the site, and will let us import and keep running mediawiki with all the wiki spam that entails. I think we can worry about that later though. I have noticed a lot of people using readthedocs.org as well, and also have no idea how that works. I'll look into that for the doxygen documentation. Rich On 06/10/2015 10:21 PM, BiggsGeoffrey wrote: > An excellent plan, Rich. > > I agree that the code is the priority. For the website, etc., they will still be usable from SF until SF decides to coopt the project. What about putting the website and so on in a branch for now until you have time to look at them? > > One possibly for the API docs is readthedocs.org. I have absolutely no idea how they operate, but I seem to be increasingly directed there for documentation. > > Geoff > ________________________________________ > From: Brian Gerkey <br...@ge...> > Sent: Thursday, 11 June 2015 10:08 a.m. > To: pla...@li... > Subject: Re: [Playerstage-developers] Is player dead? > > Ditto, +1 to that plan. > > On Wed, Jun 10, 2015 at 6:05 PM, Richard Vaughan <va...@sf...> wrote: >> Thanks Rich. Github makes sense to me too. Thanks for working on this. >> >> R/ >> >> On Wed, Jun 10, 2015 at 5:35 PM, Rich Mattes <jp...@gm...> wrote: >>> >>> Hi all, >>> >>> First, yes, I am still maintaining Player and I'm happy to accept >>> patches and field bug reports. It's not under active development >>> anymore, but it's not dead by any means. I've been chipping away at >>> things here and there, like updating drivers to support new library >>> versions and updating the xdr and interface generation scripts to work >>> with python 3. >>> >>> I'm glad this thread has popped up, as I've been thinking about the >>> sourceforge hosting situation for the past few days, and addressing it >>> has been quickly moving up my to-do list. About a year or two ago I >>> worked out the proper git-svn incantation and username/email address >>> mappings to export the entire Player svn repository history into git. >>> I'll try to dig that up again and see if I can get the tree and the >>> history into git locally. >>> >>> Github and Bitbucket are both good choices for a new host, though I lean >>> towards github because it's a lot more popular. My gameplan is to set >>> up a github organization called "playerproject" to host the code under, >>> and create a "player" repository underneath for the Player code. Once I >>> push the git tree, I'll add whichever of you would like to be part of >>> the new github org and look at migrating the issues, wiki, website, api >>> docs, etc. from sf and tagging a 3.1 release under the new >>> infrastructure. I don't have a lot of time for the rest of this month, >>> but I think I can at least get the code moved, and worry about the rest >>> once I get some more free time. >>> >>> Rich >>> >>> On 06/10/2015 07:05 PM, BiggsGeoffrey wrote: >>>> I think that they already have melted down. The recent incident with SF >>>> taking over the GIMP Windows project and bundling adware in the >>>> installer was not an isolated incident. >>>> >>>> >>>> Github would seem to be the logical choice at the moment, but I think >>>> that any migration destination should be driven by Rich's needs, to >>>> ensure he can maintain it easily. >>>> >>>> >>>> Geoff >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Richard Vaughan <va...@sf...> >>>> *Sent:* Thursday, 11 June 2015 3:04 a.m. >>>> *To:* pla...@li... >>>> *Subject:* Re: [Playerstage-developers] Is player dead? >>>> Seconding Brian's answer. Player and Stage are mature and in maintenance >>>> mode. Rich is accepting patches that fix bugs, etc. but may not respond >>>> as quickly as in past years. The code remains available and always will. >>>> >>>> By the way, we might want to migrate Player away from SourceForge before >>>> they melt down completely. >>>> >>>> Richard/ >>>> >>>> >>>> On Wed, Jun 10, 2015 at 10:35 AM, Brian Gerkey <br...@ge... >>>> <mailto:br...@ge...>> wrote: >>>> >>>> hi Fred, >>>> >>>> It's awesome to hear that you're still using Player. We put a lot >>>> of >>>> effort into that tool for many years. >>>> >>>> It's fair to say that Player is no longer under active development, >>>> but that doesn't mean that it's dead. I handed over responsibility >>>> for Player to the very capable Rich Mattes several years ago, when I >>>> turned my attention to ROS. I think that Rich is still applying >>>> patches. Looks like this is the place to submit them: >>>> http://sourceforge.net/p/playerstage/patches/ >>>> >>>> brian. >>>> >>>> On Wed, Jun 10, 2015 at 8:32 AM, Fred Labrosse <ff...@ab... >>>> <mailto:ff...@ab...>> wrote: >>>> > All, >>>> > >>>> > Sorry for the blunt question, but do I sense that player is dying? >>>> > >>>> > I’m asking because I am still using it, but see very little >>>> traffic on either mailing list and very few commits made to the svn >>>> repository. I have a few diffs to submit that have to do with ptz >>>> interfaces and the sonyevid30 driver and I was wondering if there was any >>>> point in submitting them. >>>> > >>>> > Player has been very useful to me for many years, and I would hate >>>> seeing it disappear, especially since changing to something else, such as >>>> ROS, would be quite some work for me to port some of our player code to the >>>> new system. >>>> > >>>> > Any views on that? >>>> > >>>> > Cheers, >>>> > >>>> > Fred >>>> > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ >>>> > _______________________________________________ >>>> > Playerstage-developers mailing list >>>> >Pla...@li... >>>> <mailto:Pla...@li...> >>>> >https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Playerstage-developers mailing list >>>> Pla...@li... >>>> <mailto:Pla...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >>>> _______________________________________________ >>>> Playerstage-developers mailing list >>>> Pla...@li... >>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Playerstage-developers mailing list >>> Pla...@li... >>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Playerstage-developers mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-developers >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > ------------------------------------------------------------------------------ > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
538 messages has been excluded from this view by a project administrator.
