<div>Rev 32016 - psoetens (1 file(s) modified)<div><div>macosx: Make all data and functions static to prevent multiple copies when linking

Signed-off-by: Stephen Roderick <kiwi.net@mac.com><div>~ /trunk/rtt/src/os/macosx/fosi.h

<div>Rev 32016 - psoetens (1 file(s) modified)<div><div>macosx: Make all data and functions static to prevent multiple copies when linking

Signed-off-by: Stephen Roderick <kiwi.net@mac.com><div>~ /trunk/rtt/src/os/macosx/fosi.h

<div>Rev 32015 - psoetens (2 file(s) modified)<div><div>cmake: Add boost-thread dependent library to pkgconfig file for Mac OS X

Signed-off-by: Stephen Roderick <kiwi.net@mac.com><div>~ /trunk/rtt/config/check_depend.cmake
~ /trunk/rtt/src/CMakeLists.txt

<div>Rev 32015 - psoetens (2 file(s) modified)<div><div>cmake: Add boost-thread dependent library to pkgconfig file for Mac OS X

Signed-off-by: Stephen Roderick <kiwi.net@mac.com><div>~ /trunk/rtt/config/check_depend.cmake
~ /trunk/rtt/src/CMakeLists.txt

<div>Rev 31997 - psoetens (3 file(s) modified)<div><div>Fix bug #773: Nan or segfaults in scripting when assigning int to array

The updatePartCommand implementation did not take refcounts to returned adapted
data sources.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/DataSources.hpp
~ /trunk/rtt/src/scripting/ValueChangeParser.cpp
~ /trunk/rtt/tests/program_test.cpp

<div>Rev 31997 - psoetens (3 file(s) modified)<div><div>Fix bug #773: Nan or segfaults in scripting when assigning int to array

The updatePartCommand implementation did not take refcounts to returned adapted
data sources.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/DataSources.hpp
~ /trunk/rtt/src/scripting/ValueChangeParser.cpp
~ /trunk/rtt/tests/program_test.cpp

<div>Rev 31996 - psoetens (1 file(s) modified)<div><div>Fixes race condition in EventProcessor

The args are read and stored in a
temporary variable. Then this is used to get the arguments for the function
call.
Before the args where read for each argument. You could end up with
inconsistent data the the subsequent read's where pre-empted by a call to
DataObjectLockFree.

From: Butch Slayer <butch.slayers@gmail.com><div>~ /trunk/rtt/src/EventProcessor.hpp

<div>Rev 31996 - psoetens (1 file(s) modified)<div><div>Fixes race condition in EventProcessor

The args are read and stored in a
temporary variable. Then this is used to get the arguments for the function
call.
Before the args where read for each argument. You could end up with
inconsistent data the the subsequent read's where pre-empted by a call to
DataObjectLockFree.

From: Butch Slayer <butch.slayers@gmail.com><div>~ /trunk/rtt/src/EventProcessor.hpp

<div>Rev 31995 - psoetens (2 file(s) modified)<div><div>Fix bug #766: Segfault on quit when stopping running function in program processor

If the PP::step() function did not run yet, the function is left in the f_queue and
needs to be removed from there.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/CommandExecFunction.cpp
~ /trunk/rtt/src/ProgramProcessor.cpp

<div>Rev 31995 - psoetens (2 file(s) modified)<div><div>Fix bug #766: Segfault on quit when stopping running function in program processor

If the PP::step() function did not run yet, the function is left in the f_queue and
needs to be removed from there.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/CommandExecFunction.cpp
~ /trunk/rtt/src/ProgramProcessor.cpp

<div>Rev 31978 - psoetens (4 file(s) modified)<div><div>types: fix copy-on-write race against std::string implementation

I have to write this down in case this bites us again in the future:
* Orocos scripting assumes that a string of size 'N' will not decrease
its capacity when it is assigned a string of size '< N'.
* Same for a std::vector

The testTypes unit test checks if this assumption is true. Of course,
it isn't in some cases. This patch works around one more such case.
We already worked around asigning two strings by overloading the
ValueDataSource::set() in case of string. Now we also had to overload
it's constructor in case of string.

The problem is that string uses a copy-on-write implementation that
discards previous capacity in favour of the newly written string,
and allocates a capacity equal to that string's size. Hence above
assumption fails. The only way to counter that is to 'pre-allocate'
a new string for *each* string in scripting such that it is certainly
not a copy-on-write (cow) target. Since we use 'clone()' a lot in scripting,
each clone() was a possible 'shallow string clone' which could trigger
a future 'cow'. The only work around is to make sure that clone() makes
a deep copy instead of a shallow one of the string. This is done by
passing the string::c_str() in the constructor of ValueDataSource, which
forces a 'deep' copy. The same trick had been applied in ::set() earlier.

In order to have the above work, the buildVariable() implementation for
std::string had to be adapted to fill the 'preallocated' string with
spaces instead of '\0' because the c_str() of '\0' is the empty string,
which is not what we want to use in the constructor of ValueDataSource :/

Conflicts:

rtt/types/RealTimeTypekitTypes.cpp
tests/types_test.cpp

Note: conflicts resolved for 1.x branch.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/DataSources.cpp
~ /trunk/rtt/src/DataSources.hpp
~ /trunk/rtt/src/RealTimeToolkit.cpp
~ /trunk/rtt/src/Types.cpp

<div>Rev 31978 - psoetens (4 file(s) modified)<div><div>types: fix copy-on-write race against std::string implementation

I have to write this down in case this bites us again in the future:
* Orocos scripting assumes that a string of size 'N' will not decrease
its capacity when it is assigned a string of size '< N'.
* Same for a std::vector

The testTypes unit test checks if this assumption is true. Of course,
it isn't in some cases. This patch works around one more such case.
We already worked around asigning two strings by overloading the
ValueDataSource::set() in case of string. Now we also had to overload
it's constructor in case of string.

The problem is that string uses a copy-on-write implementation that
discards previous capacity in favour of the newly written string,
and allocates a capacity equal to that string's size. Hence above
assumption fails. The only way to counter that is to 'pre-allocate'
a new string for *each* string in scripting such that it is certainly
not a copy-on-write (cow) target. Since we use 'clone()' a lot in scripting,
each clone() was a possible 'shallow string clone' which could trigger
a future 'cow'. The only work around is to make sure that clone() makes
a deep copy instead of a shallow one of the string. This is done by
passing the string::c_str() in the constructor of ValueDataSource, which
forces a 'deep' copy. The same trick had been applied in ::set() earlier.

In order to have the above work, the buildVariable() implementation for
std::string had to be adapted to fill the 'preallocated' string with
spaces instead of '\0' because the c_str() of '\0' is the empty string,
which is not what we want to use in the constructor of ValueDataSource :/

Conflicts:

rtt/types/RealTimeTypekitTypes.cpp
tests/types_test.cpp

Note: conflicts resolved for 1.x branch.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/DataSources.cpp
~ /trunk/rtt/src/DataSources.hpp
~ /trunk/rtt/src/RealTimeToolkit.cpp
~ /trunk/rtt/src/Types.cpp

<div>Rev 31977 - psoetens (1 file(s) modified)<div><div>cmake: do not fail if libxenomai is not found but libnative is.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/config/FindXenomai.cmake

<div>Rev 31977 - psoetens (1 file(s) modified)<div><div>cmake: do not fail if libxenomai is not found but libnative is.

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/config/FindXenomai.cmake

<div>Rev 31976 - psoetens (1 file(s) modified)<div><div>nameserver: fix compilation issue with GCC 4.5

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/NameServer.hpp

<div>Rev 31976 - psoetens (1 file(s) modified)<div><div>nameserver: fix compilation issue with GCC 4.5

From: Peter Soetens <peter@thesourceworks.com><div>~ /trunk/rtt/src/NameServer.hpp