Menu
▾
▴
yarp0-devel — YARP Development
This list is closed, nobody may subscribe to it.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(4) |
Feb
(2) |
Mar
(19) |
Apr
(7) |
May
|
Jun
|
Jul
(4) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(3) |
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alberto C. <alb...@ii...> - 2015-04-20 11:46:33
|
Dear YARP users, we are glad to announce that now YARP wrappers also support ROS topic messages. In particular the supported messages are: - ControlBoardWrapper2 publishes sensor_msgs/_JointState_.msg message - ServerInertial publishes sensor_msgs/_Imu_.msg message - AnalogWrapper right now supports geometry_msgs/_WrenchedStamped_.msg message but could be extended to other messages in the future if need arises. The key feature is that a YARP wrapper is able to publish a natively ROS compatible messages _without having to install any ROS library_, making it easy to configure and deploy your system. For instance a source of data, like a robot, can use this feature to publish data either through YARP or ROS (or both) using only YARP wrappers, then on the other side a ROS node can read the data by subscribing to a ROS topic. The parameters needed to configure the wrappers in order to open a ROS topic are enclosed in a ROS group and can be summarized with the following example: General parameter for all wrappers [ROS] useROS true (can be 'false', 'true' or 'only', in the latter case no YARP ports will be opened for that wrapper) ROS_topicName /JointState ROS_nodeName /robotPublisher Specific parameter for controlBoardWrapper2 jointNames r_shoulder_pitch r_shoulder_roll r_shoulder_yaw r_elbow r_wrist_prosup r_wrist_pitch r_wrist_yaw Specific parameter for ServerInertial frame_id reference_frame_name Specific parameter for analogServer frame_id reference_frame_name ROS_msgType geometry_msgs/WrenchedStamped ROS group is optional, if not present ROS initialization will be skipped and it is equivalent to put useROS equal to false. Parameters for each device are detailed in the relative doxygen page in the wiki. *For a quick test using the iCub_SIM*, follow the instruction hereafter. Step 1: on a machine with ROS installed, launch the roscore Step 2: add the following parameters to an iCub_SIM config file, for example Sim_right_arm.ini [ROS] useROS true ROS_topicName /sim/right_arm/rosTopicName ROS_nodeName /sim/right_arm/rosNodeName jointNames j0 j1 j2 j3 j4 j5 j6 j7 j8 j9 j10 j11 j12 j13 j14 j15 Step 3: connect the yarpserver to the roscore. - set ROS_MASTER_URI environment variable to the ip address of the roscore, like explained in the ROS documentation http://wiki.ros.org/ROS/EnvironmentVariables#ROS_MASTER_URI - launch yarp server with "yarpserevr --ros" to establish a connection between to the roscore (must be running somewhere). Step 4: start the iCub_SIM Step 5: verify ROS topic functionalities. - rostopic list will print as output /sim/right_arm/rosNodeName -rostopic info /sim/right_arm/rosNodeName will print as output: Type: sensor_msgs/JointState Publishers: * /sim/right_arm/rosNodeName (http://172.16.158.1:10030) Subscribers: None -rostopic echo /sim/right_arm/rosNodeName will print the data --- header: seq: 6172 stamp: secs: 1429529788 nsecs: 624928000 frame_id: '' name: ['j0', 'j1', 'j2', 'j3', 'j4', 'j5', 'j6', 'j7', 'j8', 'j9', 'j10', 'j11', 'j12', 'j13', 'j14', 'j15'] position: [-0.4363134232077414, 0.3490567847758154, 2.2340960932181873e-06, 0.8726677899833618, 6.231653478018042e-07, 1.8754167368881575e-08, 1.5271788351811566e-07, 1.0297615223056957, 0.3490717025053828, 0.34907170233369883, 0.3490717026486767, 0.17453585098231797, 0.174535850838284, 0.17453585100877306, 0.17453585085117923, 0.1745358540914655] velocity: [-1.6946113987326777e-06, -3.3540582317576583e-06, 8.411652280514529e-07, 4.559300447136039e-07, -1.3959037290565161e-08, 1.3144826190984973e-08, -5.87885290399614e-09, 1.7466279554175236e-10, 1.843954560227913e-10, -1.249781410921814e-10, 8.48785918906594e-11, 2.779529433118688e-10, 1.199568207945057e-10, 2.96780928330086e-10, 1.1803821667477136e-10, 5.36649803111618e-10] effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] For any question or feedback, check the doxygen documentation or write an email. Alberto Cardellino |
|
From: Daniele E. D. <dan...@ii...> - 2015-04-15 13:02:20
|
Hello Giovanni, Thanks for the information, it looks promising. The concept is very similar to git annex, but with some differences that makes it interesting. On 13/04/15 18:46, Lorenzo Natale wrote: > We mostly need a place for storing binary releases so that > we can stop hosting them on sourceforce (which is confusing). > Binaries are quite large and would soon fill the quota of > 1Gb. If I understand correctly, the storage does not have to be on github.com, but on any git server that implements the specification. I wouldn't recommend to be early adopters for yarp/icub, but I'll definitely keep an eye on that. Cheers, Daniele |
|
From: Giovanni S. <gsa...@is...> - 2015-04-13 18:13:17
|
On 13 April 2015 at 17:46, Lorenzo Natale <Lor...@ii...> wrote: >> -----Original Message----- >> From: Giovanni Saponaro [mailto:gsa...@is...] >> Git Large File Storage >> https://github.com/blog/1986-announcing-git-large-file-storage-lfs > > Thank you Giovanni, > Nice! > > Some comments: > > We mostly need a place for storing binary releases so that we can stop hosting them on sourceforce (which is confusing). Binaries are quite large and would soon fill the quota of 1Gb. Git LFS handles pointers/urls to big files, which can then be hosted on any server. So if the server with the large files is not github.com, this could work with little effort/cost. I haven't tested this yet, I'm waiting for their early access email with further instructions. > The other concern is that you need a special git client -- is this correct? -- this may be annoying. True, for now it needs a separate program (extension). However, having an open protocol (https://github.com/github/git-lfs/blob/master/docs/spec.md) and being endorsed by GitHub, it might be supported by common clients in the future. Ciao, -Giovanni |
|
From: Lorenzo N. <Lor...@ii...> - 2015-04-13 16:46:27
|
Thank you Giovanni, Nice! Some comments: We mostly need a place for storing binary releases so that we can stop hosting them on sourceforce (which is confusing). Binaries are quite large and would soon fill the quota of 1Gb. The other concern is that you need a special git client -- is this correct? -- this may be annoying. Lorenzo > -----Original Message----- > From: Giovanni Saponaro [mailto:gsa...@is...] > Sent: lunedì 13 aprile 2015 14:26 > To: Daniele Domenichelli > Cc: Rob...@li...; yar...@li... > Subject: Re: [YARP-devel] yarp: migration to git > > On 7 March 2013 at 16:29, Daniele E. Domenichelli > <dan...@ii...> wrote: > > Hi all, > > With regard to this old thread: > > > On Thursday 07 March 2013 15:33:43 Giovanni Saponaro wrote: > > > I don't understand why iCub would be "too large for git" - but > > > perhaps the space available for a free github account is limited. > > > > Git doesn't have a good support for large binary files, therefore "too > > large for git" was a simplification of "has several binary files, > > firmware, etc." Also the iCub repository is made of several modules > > Git Large File Storage > https://github.com/blog/1986-announcing-git-large-file-storage-lfs > > A note on pricing: > Every user and organization on GitHub.com with Git LFS enabled will begin with > 1 GB of free file storage and a monthly bandwidth quota of > 1 GB. If your workflow requires higher quotas, you can easily purchase more > storage and bandwidth for your account. > > Ciao, > Giovanni > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop > your own process in accordance with the BPMN 2 standard Learn Process > modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaig > n=VA_SF > _______________________________________________ > Yarp0-devel mailing list > Yar...@li... > https://lists.sourceforge.net/lists/listinfo/yarp0-devel |
|
From: Giovanni S. <gsa...@is...> - 2015-04-13 12:55:23
|
On 7 March 2013 at 16:29, Daniele E. Domenichelli <dan...@ii...> wrote: Hi all, With regard to this old thread: > On Thursday 07 March 2013 15:33:43 Giovanni Saponaro wrote: > > I don't understand why iCub would be "too large for git" - but perhaps > > the space available for a free github account is limited. > > Git doesn't have a good support for large binary files, therefore "too > large for git" was a simplification of "has several binary files, > firmware, etc." Also the iCub repository is made of several modules Git Large File Storage https://github.com/blog/1986-announcing-git-large-file-storage-lfs A note on pricing: Every user and organization on GitHub.com with Git LFS enabled will begin with 1 GB of free file storage and a monthly bandwidth quota of 1 GB. If your workflow requires higher quotas, you can easily purchase more storage and bandwidth for your account. Ciao, Giovanni |
|
From: Alberto C. <alb...@ii...> - 2015-04-01 12:45:56
|
Dear YARP users,
In order to enhance the user-friendliness experience of YARP devices, a
small change about how yarp wrappers generate the port names to be
opened has been made.
All changes are back-compatible and warning messages will guide you
highlighting the differences and how to modify the configuration files
in order to correctly comply with the new policy.
Now all wrapper devices, namely:
- controlBoardWrapper
- analogServer
- serverInertial
will simply uses the following configuration parameter to get the port name:
name <full_name_of_the_port_here>
The names must include the leading '/', for the controlBoarWrapper the
parameter needs to be the complete prefix for the final ports, for
example if the desired port name is:
/robotName/partName/state:o
/robotName/partName/stateExt:o
/robotName/partName/command:i
/robotName/partName/rpc:i
then, the 'name' parameter has to be '/robotName/partName' (whitout
trailing '/'), as the suffixes will be automatically added.
For the analogServer, the suffix 'analog:o' will not be added
automatically anymore but the user can now specify the complete port
name to use. The advantage of this approach is that the user can
customize the portname in order to integrate information about the data
type for that particular analog sensor. e.g:
/robotName/robotPart/sensorType
The rpc:i suffix will be added to the provided name for the RPC port.
If you want to use the new policy, but still have the same port name in
order to gradually update the application, simply copy-paste the current
portname in the 'name' parameter field.
For any question or feedback, check the doxygen documentation or drop by
an email.
Alberto Cardellino
|
|
From: Keresztfalvi, L. <lke...@gm...> - 2015-02-27 12:19:32
|
Hi Paul, Ok, I head to the issue tracker. I didn't want to report known problems because we just began to test with and use YARP. The SWIG is very new to me and it is not easy to track down problems via the higher level language, the generated stubs and bindings, the SWIG template files and the make files. I will look into the callback's SWIG annotations (director) before reporting it, thanks for the head up. In the mean time we found another problem with the port name's length what I'll report but I would thank you for any hint where to try to find the cause: both Java and C# can open(src) the port and so register in the yarp server (shown on the list) but when connect(src,dst) is called the application fails if the src length is more than 15 characters (though the server shows them connected). Thank you, Laszlo On Thu, Feb 26, 2015 at 11:24 PM, Paul Fitzpatrick <pau...@al...> wrote: > Hi Laszlo, > > A good place for yarp questions is to file them as github issues (we > accept questions as issues particularly since they often recur or lead > to code/doc improvements) > https://github.com/robotology/yarp/issues > > Generally for overriding to work in a class, they need to be marked as > "director" in bindings/yarp.i. The number of classes marked like this > is kept low since it does impact performance. The "*Callback" classes > are currently marked as directors, classes like Bottle or > BufferedPortBottle are currently not. > > I'd have expected the first method you used, which worked in Java, to > also work in C#. Sounds like there's a bug somewhere. Can you file > this on github and we'll take a look? > > Cheers, > Paul > > On 02/26/2015 10:34 AM, Keresztfalvi, Laszlo wrote: > > Hello, > > > > I asked this question on rob...@li... > > <mailto:rob...@li...> but I am not sure > > which list is the proper place. > > (or I might asked something very dummy since I got no answer :) > > > > Callback methods are not working properly under C# and Java. > > We test with the latest stable build. Is there a chance that this > > issue has been resolved in the git? > > > > Yarp version: 2.3.63 windows binary; Swig 3.0.5; Oracle JDK 1.8.0_31 > > > > * By extending the _BottleCallback_ class the onRead() method is > > _invoked under Java_ as excepted but the same method under _C# is > > *not* invoked_. > > > > * By extending _BufferedPortBottle_ and overriding its onRead() > > method then using port's useCallback() the onRead(Bottle datum) > > method is _not invoked_ neither in Java nor in C#. > > > > > > Sample code: > > > > Network.init(); > > BufferedPortBottle _port = new BufferedPort(); > > MyBottleCallback _callback = new MyBottleCallback(); // extends > > BottleCallback overrides method onRead(Bottle datum) > > _port.open("/read"); > > _port.useCallback(_callback); > > > > Any advise? > > > > Thank you, > > Laszlo > > > > > > > > > ------------------------------------------------------------------------------ > > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > > by Intel and developed in partnership with Slashdot Media, is your hub > for all > > things parallel software development, from weekly thought leadership > blogs to > > news, videos, case studies, tutorials and more. Take a look and join the > > conversation now. http://goparallel.sourceforge.net/ > > > > > > _______________________________________________ > > Yarp0-devel mailing list > > Yar...@li... > > https://lists.sourceforge.net/lists/listinfo/yarp0-devel > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Yarp0-devel mailing list > Yar...@li... > https://lists.sourceforge.net/lists/listinfo/yarp0-devel > |
|
From: Paul F. <pau...@al...> - 2015-02-26 22:24:42
|
Hi Laszlo, A good place for yarp questions is to file them as github issues (we accept questions as issues particularly since they often recur or lead to code/doc improvements) https://github.com/robotology/yarp/issues Generally for overriding to work in a class, they need to be marked as "director" in bindings/yarp.i. The number of classes marked like this is kept low since it does impact performance. The "*Callback" classes are currently marked as directors, classes like Bottle or BufferedPortBottle are currently not. I'd have expected the first method you used, which worked in Java, to also work in C#. Sounds like there's a bug somewhere. Can you file this on github and we'll take a look? Cheers, Paul On 02/26/2015 10:34 AM, Keresztfalvi, Laszlo wrote: > Hello, > > I asked this question on rob...@li... > <mailto:rob...@li...> but I am not sure > which list is the proper place. > (or I might asked something very dummy since I got no answer :) > > Callback methods are not working properly under C# and Java. > We test with the latest stable build. Is there a chance that this > issue has been resolved in the git? > > Yarp version: 2.3.63 windows binary; Swig 3.0.5; Oracle JDK 1.8.0_31 > > * By extending the _BottleCallback_ class the onRead() method is > _invoked under Java_ as excepted but the same method under _C# is > *not* invoked_. > > * By extending _BufferedPortBottle_ and overriding its onRead() > method then using port's useCallback() the onRead(Bottle datum) > method is _not invoked_ neither in Java nor in C#. > > > Sample code: > > Network.init(); > BufferedPortBottle _port = new BufferedPort(); > MyBottleCallback _callback = new MyBottleCallback(); // extends > BottleCallback overrides method onRead(Bottle datum) > _port.open("/read"); > _port.useCallback(_callback); > > Any advise? > > Thank you, > Laszlo > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > > > _______________________________________________ > Yarp0-devel mailing list > Yar...@li... > https://lists.sourceforge.net/lists/listinfo/yarp0-devel |
|
From: Keresztfalvi, L. <lke...@gm...> - 2015-02-26 09:35:45
|
Hello,
I asked this question on rob...@li... but I am
not sure which list is the proper place.
(or I might asked something very dummy since I got no answer :)
Callback methods are not working properly under C# and Java.
We test with the latest stable build. Is there a chance that this issue has
been resolved in the git?
Yarp version: 2.3.63 windows binary; Swig 3.0.5; Oracle JDK 1.8.0_31
- By extending the *BottleCallback* class the onRead() method is *invoked
under Java* as excepted but the same method under *C# is not invoked*.
- By extending *BufferedPortBottle* and overriding its onRead() method
then using port's useCallback() the onRead(Bottle datum) method is *not
invoked* neither in Java nor in C#.
Sample code:
Network.init();
BufferedPortBottle _port = new BufferedPort();
MyBottleCallback _callback = new MyBottleCallback(); // extends
BottleCallback overrides method onRead(Bottle datum)
_port.open("/read");
_port.useCallback(_callback);
Any advise?
Thank you,
Laszlo
|
|
From: Daniele E. D. <dan...@ii...> - 2014-03-26 20:18:38
|
Dear all, As you might already know, supporting gtk2 on 3 different platform on all the supported compilers has been a _huge_ effort in the last couple of years, and currently GUIs built with some recent Visual Studio version are broken and not easily fixable. We started investigating alternatives, and we agreed that switching to Qt5 is easier than fixing these problems. (The decision was already taken, so please don't start a flame war). Therefore we are working to port the YARP GUIs (and probably iCub GUIs later), to Qt5. At the moment we started porting yarpview, yarpscope and gyarpmanager. If you are curious to see the result, the code is available, you can find them here: https://github.com/robotology-playground/qtyarp/ In the same page you can find the build instruction. Note that these GUIs are still experimental and might contain bug. Please test and report any bug you should find here: https://github.com/robotology-playground/qtyarp/issues Regards, Daniele |
|
From: Giovanni S. <gsa...@is...> - 2014-02-18 15:23:27
|
On 18 February 2014 12:16, Lorenzo Natale <Lor...@ii...> wrote: > Can you post it as a bug in github? > > (2.3.61 is an unofficial release mostly made for testing) Thanks Lorenzo, Paul, Issue posted (#129). Cheers, -Giovanni |
|
From: Paul F. <pau...@al...> - 2014-02-18 15:01:17
|
Yes, that looks like my goof in some new code. Sorry! Will take a look now. As Lorenzo suggests, please file an issue (it helps us keep track of things): https://github.com/robotology/yarp/issues/new Best, Paul On 02/18/2014 01:16 PM, Lorenzo Natale wrote: > Hi Giovanni, > this seems related to a new feature that was introduced recently. > > Can you post it as a bug in github? > > (2.3.61 is an unofficial release mostly made for testing) > > Thank you, > Lorenzo > >> -----Original Message----- >> From: Giovanni Saponaro [mailto:gsa...@is...] >> Sent: martedì 18 febbraio 2014 12:48 >> To: RobotCub Mailinglist; yar...@li... >> Cc: Afonso Gonçalves >> Subject: [YARP-devel] yarpview segmentation fault >> >> Dear hackers, >> >> We installed yarp from git sources (2.3.61) on a new machine with Ubuntu >> 12.04 64-bit. We confirmed all the required dependencies from >> http://wiki.icub.org/wiki/Linux:_dependencies to be present on the system. We >> incurred in the following problem with yarpview: >> >> $ ./yarpview >> Segmentation fault (core dumped) >> >> Running it in gdb yields: >> Starting program: /home/afonsogoncalves/Workspace/yarp/build/bin/yarpview >> warning: no loadable sections found in added symbol-file system-supplied DSO >> at 0x7ffff7ffa000 [Thread debugging using libthread_db enabled] Using host >> libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00000000004c0c6e in yarp::os::Time::now () >> at >> /home/afonsogoncalves/Workspace/yarp/src/libYARP_OS/src/Time.cpp:70 >> 70 return getClock().now(); >> (gdb) >> >> For comparison, we also installed yarp 2.3.22 and in this version yarpview >> works on the system. >> >> Any ideas? Thanks, >> -Giovanni >> |
|
From: Lorenzo N. <Lor...@ii...> - 2014-02-18 12:17:00
|
Hi Giovanni, this seems related to a new feature that was introduced recently. Can you post it as a bug in github? (2.3.61 is an unofficial release mostly made for testing) Thank you, Lorenzo > -----Original Message----- > From: Giovanni Saponaro [mailto:gsa...@is...] > Sent: martedì 18 febbraio 2014 12:48 > To: RobotCub Mailinglist; yar...@li... > Cc: Afonso Gonçalves > Subject: [YARP-devel] yarpview segmentation fault > > Dear hackers, > > We installed yarp from git sources (2.3.61) on a new machine with Ubuntu > 12.04 64-bit. We confirmed all the required dependencies from > http://wiki.icub.org/wiki/Linux:_dependencies to be present on the system. We > incurred in the following problem with yarpview: > > $ ./yarpview > Segmentation fault (core dumped) > > Running it in gdb yields: > Starting program: /home/afonsogoncalves/Workspace/yarp/build/bin/yarpview > warning: no loadable sections found in added symbol-file system-supplied DSO > at 0x7ffff7ffa000 [Thread debugging using libthread_db enabled] Using host > libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004c0c6e in yarp::os::Time::now () > at > /home/afonsogoncalves/Workspace/yarp/src/libYARP_OS/src/Time.cpp:70 > 70 return getClock().now(); > (gdb) > > For comparison, we also installed yarp 2.3.22 and in this version yarpview > works on the system. > > Any ideas? Thanks, > -Giovanni > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications Take advantage of > what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktr > k > _______________________________________________ > Yarp0-devel mailing list > Yar...@li... > https://lists.sourceforge.net/lists/listinfo/yarp0-devel |
|
From: Giovanni S. <gsa...@is...> - 2014-02-18 11:48:03
|
Dear hackers, We installed yarp from git sources (2.3.61) on a new machine with Ubuntu 12.04 64-bit. We confirmed all the required dependencies from http://wiki.icub.org/wiki/Linux:_dependencies to be present on the system. We incurred in the following problem with yarpview: $ ./yarpview Segmentation fault (core dumped) Running it in gdb yields: Starting program: /home/afonsogoncalves/Workspace/yarp/build/bin/yarpview warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00000000004c0c6e in yarp::os::Time::now () at /home/afonsogoncalves/Workspace/yarp/src/libYARP_OS/src/Time.cpp:70 70 return getClock().now(); (gdb) For comparison, we also installed yarp 2.3.22 and in this version yarpview works on the system. Any ideas? Thanks, -Giovanni |
|
From: Paul F. <pau...@al...> - 2013-08-06 13:35:24
|
For WIN32, I think some yarp programs may already use it.
$YARP_ROOT/src/yarpview/CMakeLists.txt has this logic:
if(WIN32 AND NOT CYGWIN)
add_definitions(-DYARP_WIN32_NOCONSOLE)
add_executable(yarpview WIN32 ${folder_source} ${folder_header})
else(WIN32 AND NOT CYGWIN)
add_executable(yarpview ${folder_source} ${folder_header})
endif(WIN32 AND NOT CYGWIN)
I *think* the main thing going on here is that if you start yarpview by
clicking on an icon, with WIN32 in use you won't see a DOS (or whatever
it is now) console opening up.
Definitely be good to have win+osx people play with these settings,
Cheers,
P
On 08/06/2013 10:51 AM, Daniele E. Domenichelli wrote:
> Hello,
>
> By looking at the documentation of the add_executable cmake command,
> I found that it supports 2 extra flags: WIN32 and MACOSX_BUNDLE.
> They seem to enable some specific features for GUI executables on
> windows and mac (see the documentation below).
> Do you think these are useful for YARP GUIs? Can anyone on windows
> or on mac test them and try to understand the differences?
>
>
> Cheers,
> Daniele
>
>
> ----
>
> $ cmake --help-command add_executable
> cmake version 2.8.11.2
> add_executable
> Add an executable to the project using the specified source files.
>
> add_executable(<name> [WIN32] [MACOSX_BUNDLE]
> [EXCLUDE_FROM_ALL]
> source1 source2 ... sourceN)
>
> Adds an executable target called<name> to be built from the source
> files listed in the command invocation. The<name> corresponds to the
> logical target name and must be globally unique within a project. The
> actual file name of the executable built is constructed based on
> conventions of the native platform (such as<name>.exe or just
> <name>).
>
> By default the executable file will be created in the build tree
> directory corresponding to the source tree directory in which the
> command was invoked. See documentation of the
> RUNTIME_OUTPUT_DIRECTORY target property to change this location. See
> documentation of the OUTPUT_NAME target property to change the<name>
> part of the final file name.
>
> If WIN32 is given the property WIN32_EXECUTABLE will be set on the
> target created. See documentation of that target property for
> details.
>
> If MACOSX_BUNDLE is given the corresponding property will be set on
> the created target. See documentation of the MACOSX_BUNDLE target
> property for details.
>
> If EXCLUDE_FROM_ALL is given the corresponding property will be set on
> the created target. See documentation of the EXCLUDE_FROM_ALL target
> property for details.
>
> The add_executable command can also create IMPORTED executable targets
> using this signature:
>
> add_executable(<name> IMPORTED [GLOBAL])
>
> An IMPORTED executable target references an executable file located
> outside the project. No rules are generated to build it. The target
> name has scope in the directory in which it is created and below, but
> the GLOBAL option extends visibility. It may be referenced like any
> target built within the project. IMPORTED executables are useful for
> convenient reference from commands like add_custom_command. Details
> about the imported executable are specified by setting properties
> whose names begin in "IMPORTED_". The most important such property is
> IMPORTED_LOCATION (and its per-configuration version
> IMPORTED_LOCATION_<CONFIG>) which specifies the location of the main
> executable file on disk. See documentation of the IMPORTED_*
> properties for more information.
>
> $ cmake --help-property WIN32_EXECUTABLE
> cmake version 2.8.11.2
> WIN32_EXECUTABLE
> Build an executable with a WinMain entry point on windows.
>
> When this property is set to true the executable when linked on
> Windows will be created with a WinMain() entry point instead of just
> main(). This makes it a GUI executable instead of a console
> application. See the CMAKE_MFC_FLAG variable documentation to
> configure use of MFC for WinMain executables. This property is
> initialized by the value of the variable CMAKE_WIN32_EXECUTABLE if it
> is set when a target is created.
>
> $ cmake --help-property MACOSX_BUNDLE
> cmake version 2.8.11.2
> MACOSX_BUNDLE
> Build an executable as an application bundle on Mac OS X.
>
> When this property is set to true the executable when built on Mac OS
> X will be created as an application bundle. This makes it a GUI
> executable that can be launched from the Finder. See the
> MACOSX_BUNDLE_INFO_PLIST target property for information about
> creation of the Info.plist file for the application bundle. This
> property is initialized by the value of the variable
> CMAKE_MACOSX_BUNDLE if it is set when a target is created.
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Yarp0-devel mailing list
> Yar...@li...
> https://lists.sourceforge.net/lists/listinfo/yarp0-devel
|
|
From: Daniele E. D. <dan...@ii...> - 2013-08-06 08:51:17
|
Hello,
By looking at the documentation of the add_executable cmake command,
I found that it supports 2 extra flags: WIN32 and MACOSX_BUNDLE.
They seem to enable some specific features for GUI executables on
windows and mac (see the documentation below).
Do you think these are useful for YARP GUIs? Can anyone on windows
or on mac test them and try to understand the differences?
Cheers,
Daniele
----
$ cmake --help-command add_executable
cmake version 2.8.11.2
add_executable
Add an executable to the project using the specified source files.
add_executable(<name> [WIN32] [MACOSX_BUNDLE]
[EXCLUDE_FROM_ALL]
source1 source2 ... sourceN)
Adds an executable target called <name> to be built from the source
files listed in the command invocation. The <name> corresponds to the
logical target name and must be globally unique within a project. The
actual file name of the executable built is constructed based on
conventions of the native platform (such as <name>.exe or just
<name>).
By default the executable file will be created in the build tree
directory corresponding to the source tree directory in which the
command was invoked. See documentation of the
RUNTIME_OUTPUT_DIRECTORY target property to change this location. See
documentation of the OUTPUT_NAME target property to change the <name>
part of the final file name.
If WIN32 is given the property WIN32_EXECUTABLE will be set on the
target created. See documentation of that target property for
details.
If MACOSX_BUNDLE is given the corresponding property will be set on
the created target. See documentation of the MACOSX_BUNDLE target
property for details.
If EXCLUDE_FROM_ALL is given the corresponding property will be set on
the created target. See documentation of the EXCLUDE_FROM_ALL target
property for details.
The add_executable command can also create IMPORTED executable targets
using this signature:
add_executable(<name> IMPORTED [GLOBAL])
An IMPORTED executable target references an executable file located
outside the project. No rules are generated to build it. The target
name has scope in the directory in which it is created and below, but
the GLOBAL option extends visibility. It may be referenced like any
target built within the project. IMPORTED executables are useful for
convenient reference from commands like add_custom_command. Details
about the imported executable are specified by setting properties
whose names begin in "IMPORTED_". The most important such property is
IMPORTED_LOCATION (and its per-configuration version
IMPORTED_LOCATION_<CONFIG>) which specifies the location of the main
executable file on disk. See documentation of the IMPORTED_*
properties for more information.
$ cmake --help-property WIN32_EXECUTABLE
cmake version 2.8.11.2
WIN32_EXECUTABLE
Build an executable with a WinMain entry point on windows.
When this property is set to true the executable when linked on
Windows will be created with a WinMain() entry point instead of just
main(). This makes it a GUI executable instead of a console
application. See the CMAKE_MFC_FLAG variable documentation to
configure use of MFC for WinMain executables. This property is
initialized by the value of the variable CMAKE_WIN32_EXECUTABLE if it
is set when a target is created.
$ cmake --help-property MACOSX_BUNDLE
cmake version 2.8.11.2
MACOSX_BUNDLE
Build an executable as an application bundle on Mac OS X.
When this property is set to true the executable when built on Mac OS
X will be created as an application bundle. This makes it a GUI
executable that can be launched from the Finder. See the
MACOSX_BUNDLE_INFO_PLIST target property for information about
creation of the Info.plist file for the application bundle. This
property is initialized by the value of the variable
CMAKE_MACOSX_BUNDLE if it is set when a target is created.
|
|
From: Daniele E. D. <dan...@ii...> - 2013-08-05 13:58:54
|
Hello all, On Monday 29 July 2013 13:04:26 Daniele E. Domenichelli wrote: > YARP 2.3.22 was released. > Binary packages will be avaiable soon. Also a new release of the iCub > software will be released soon. YARP 2.3.22 and iCub 1.1.13 binary packages for windows and linux are now available. You can download them from sourceforge or from our repositories for debian and ubuntu. Regards, Daniele |
|
From: Daniele E. D. <dan...@ii...> - 2013-08-01 14:25:20
|
Hello Konstantinos, On Thursday 01 August 2013 15:46:26 you wrote: > I am trying to keep my yarp install at 2.3.22, as Danielle suggested. > > Problem is, that latest iCub checkout demands Yarp 2.3.60. Any > workarounds? If you are using git just do a normal clone and then: git checkout 89f64b1e596ea28a5a090a84a00ec50f8a7fceac If you are using svn: svn co -r5838 https://github.com/robotology/yarp/trunk yarp-r5838 or if you already have a checkout svn update -r5838 Regards, Daniele |
|
From: Daniele E. D. <dan...@ii...> - 2013-07-30 15:00:56
|
On Monday 29 July 2013 13:12:17 Daniele E. Domenichelli wrote:
> In the next few days we are going to merge the yarp-2.4 branch into
> master. There are a few important changes and new features, but it is
> still unstable and subject to modifications.
> Therefore we recommend to keep using the 2.3.22 version and not
> updating from master until 2.4 is ready.
The latest "safe" commit is 89f64b1e596ea28a5a090a84a00ec50f8a7fceac or
you can checkout the tag v2.3.22
If you are using SVN through github wrapper you cannot checkout a tag
easily, therefore I suggest updating the commit number 5838 (that should
correspond to commit 89f64b1e...).
Please remember that we are trying to keep compatibility with the 2.3
releases, and to mark stuff as deprecated instead of removing them but
"2.4" features are not stable yet, and can break anytime.
One important breaking change, is that the cmake variable
YARP_MODULE_PATH will be in 2.4 a real "PATH" and therefore could be a
list and not a single directory. This might break in a few cases (i.e.
when used in include(${YARP_MODULE_PATH}/something.cmake)
You should start fixing all these occurrences, so that it won't break
when you update. There are 2 options
* Use the variable YARP_MODULE_DIR (available since YARP 2.3.22,
therefore you should require at least that version) instead of
YARP_MODULE_PATH
include(${YARP_MODULE_DIR}/something.cmake)
* Add YARP_MODULE_PATH to the CMAKE_MODULE_PATH variable and use the
filename without the path and the extension (should work with any YARP
version)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${YARP_MODULE_PATH})
include(something)
Regards,
Daniele
|
|
From: Daniele E. D. <dan...@ii...> - 2013-07-29 11:12:29
|
In the next few days we are going to merge the yarp-2.4 branch into master. There are a few important changes and new features, but it is still unstable and subject to modifications. Therefore we recommend to keep using the 2.3.22 version and not updating from master until 2.4 is ready. In the same way, the iCub repository will be ported to use the new features, and therefore we recommend to use iCub 1.1.13 (to be released very soon) and not to update from SVN until further notice Regards, Daniele |
|
From: Daniele E. D. <dan...@ii...> - 2013-07-29 11:04:35
|
YARP 2.3.22 was released. This is (probably) the last release of the 2.3 series. You can download the source code from here: https://sourceforge.net/projects/yarp0/files/yarp2/yarp-2.3.22/ Binary packages will be avaiable soon. Also a new release of the iCub software will be released soon. Regards, Daniele |
|
From: Daniele E. D. <dan...@ii...> - 2013-07-11 15:13:22
|
Testing if the mailing list is working again, sorry for the spam. Daniele |
|
From: Daniele E. D. <dan...@ii...> - 2013-04-19 08:55:25
|
Hello all, YARP Repository has finally been migrated to git! \o/ The main repository is now on GitHub. One of the reasons why we chose it, is because it has SVN support. Therefore users that don't have time to learn a new tool, will have a smoother transition. More info about GitHub SVN support can be found here: https://github.com/blog/626-announcing-svn-support https://github.com/blog/966-improved-subversion-client-support Please note that we'll keep using the SourceForge website for uploading the release files. Also note that, at the moment, the SourceForge SVN repository still exists, but it is read-only, so it won't get any new update, and will probably disappear soon. --- To clone the repository, you can use one of these addresses: * (git read-only) git://github.com/robotology/yarp.git * (ssh read+write) gi...@gi...:robotology/yarp.git * (https read+write) https://github.com/robotology/yarp.git for example: git clone git://github.com/robotology/yarp.git To use it through SVN, you will have to do a new checkout (the old one is not compatible): svn checkout https://github.com/robotology/yarp/trunk yarp --- The repository can be browsed online at the page https://github.com/robotology/yarp >From the same page you can also create personal forks that you can use to create "pull requests" https://help.github.com/articles/fork-a-repo https://help.github.com/articles/using-pull-requests --- We are planning to start using GitHub bug tracker, therefore, if you have bugs to report (only _YARP_ bugs, not iCub ones), please consider doing it here: https://github.com/robotology/yarp/issues --- If you are not familiar with git, GitHub has a lot of good resources, and a quick interactive tutorial here: https://help.github.com/ http://try.github.io/ If you need support, you can write us on the yarp0-devel or on the robocub-hackers mailing list, or you can join us on IRC (#yarpers channel on freenode). --- During git migration, we took the occasion to get rid of some very outdated stuff that was on the YARP svn, it can still be found here. https://github.com/robotology-legacy If you are using something from there, please let us know what and why, so that eventually we'll consider moving it back into the main repository. --- The real migration was performed using svn2git and following the instructions that can be found here: http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git A big thank is due to the authors of the tool and of the wiki page. If you are interested, you can have a look at the rules we used for the migration here: https://github.com/robotology-legacy/yarp0-ruleset Best regards, Daniele |
|
From: Lorenzo N. <Lor...@ii...> - 2013-04-18 12:59:18
|
Dear all, The work on the repository is proceeding smoothly. iCub The sourceforge upgrade was completed and we are currently checking the consistency of the repository. Commits are in the meanwhile disabled but you can checkout the code using svn (see http://wiki.icub.org/wiki/Sourceforge_migration). EFAA The upgrade was also completed and tested. You can checkout and commit code using svn (see http://wiki.icub.org/wiki/Sourceforge_migration). YARP. We are currently migrating the YARP repository to github. In the meanwhile we had to upgrade the repository on sourceforce. Therefore you may have received a message from sourceforge with a new url. Note that this is the new url of the repository on sourceforge. You can ignore it since this repository will be superseded once the migration to github is finished (at that point we will circulate the final url for checkout). Hope this helps to clarify the situation. Let me know if you have problems or questions. Cheers, Lorenzo |
|
From: Daniele E. D. <dan...@ii...> - 2013-04-18 07:24:40
|
Hello, as anticipated we started YARP migration to git. Commit permissions have been temporarily revoked to everyone, and the upgrade process will start as soon as the backups are ready. I'll keep you posted about further developments. Cheers, Daniele |