Important Win32 progress on master branch

I've been stress-testing the toolchain on Windows (Visual Studio Express 2005)
and have fixed numerous bugs that were still present on the master branch.
Although most are cosmetic, some should get immediate attention from current
Toolchain 2.x win32 users. These are:

http://gitorious.org/orocos-toolchain/rtt/commits :
5955532 corba: fix double delete in data flow channel cleanup
bed1fe4 win32: always build with intrinsics
baa60d4 win32: fix major bug for synchronizing with terminating thread.
06a4fb1 types: break TypeInfo API by returning shared_ptr instead of ptr
5e0d3f4 base: fix initialisation of oro_atomic_t
8c99b7f locked: fix major bug in LockedQueue::dequeue function.

The thread synchronization bugfix, which is present on the 1.x lines, was not
ported to 2.x and was only now merged on master. This explains some crashes
when Thread objects were being terminated on win32.

Also note that OS_NO_ASM is for the moment not supported on the win32 platform
(that's the inverse as with RTT 1.x!) and that you must leave this flag off (=
the default).

The unit tests only work properly after a 'make install' step and after
copying some DLL's around. We don't have rpaths on win32. Blame Microsoft.

I had to break (read: fix) the TypeInfo API in order to fix-up shared-ptr
madness. This shouldn't do much with existing typekits, since the functions
are implemented in TemplateTypeInfo, from which all typekits inherit.

If you have a running RTT 2.x system, consider cherry-picking some of these
patches if you're not going to upgrade to 2.3 immediately.

Some 'minor' unit tests are still failing, especially some more advanced
scripting magic. This needs to be nailed down, but I hope the current patches
provide a more stable platform to investigate the remaining issues.

Peter

Important Win32 progress on master branch

On 18/02/2011 00:40, Peter Soetens wrote:
> I've been stress-testing the toolchain on Windows (Visual Studio Express 2005)
> and have fixed numerous bugs that were still present on the master branch.
> Although most are cosmetic, some should get immediate attention from current
> Toolchain 2.x win32 users. These are:
>
> http://gitorious.org/orocos-toolchain/rtt/commits :
> 5955532 corba: fix double delete in data flow channel cleanup
> bed1fe4 win32: always build with intrinsics
> baa60d4 win32: fix major bug for synchronizing with terminating thread.
> 06a4fb1 types: break TypeInfo API by returning shared_ptr instead of ptr
> 5e0d3f4 base: fix initialisation of oro_atomic_t
> 8c99b7f locked: fix major bug in LockedQueue::dequeue function.

That's terrific ! I'll test these patches in the afternoon (and hope it
will fix the thread-related heap corruption bug). I see you pushed some
compilation warning fixes. What is the policy regarding 64bits build
warnings (there are hundreds of them) ?

Important Win32 progress on master branch

On Friday 18 February 2011 08:42:35 Jean Sreng wrote:
> On 18/02/2011 00:40, Peter Soetens wrote:
> > I've been stress-testing the toolchain on Windows (Visual Studio Express
> > 2005) and have fixed numerous bugs that were still present on the master
> > branch. Although most are cosmetic, some should get immediate attention
> > from current Toolchain 2.x win32 users. These are:
> >
> > http://gitorious.org/orocos-toolchain/rtt/commits :
> > 5955532 corba: fix double delete in data flow channel cleanup
> > bed1fe4 win32: always build with intrinsics
> > baa60d4 win32: fix major bug for synchronizing with terminating thread.
> > 06a4fb1 types: break TypeInfo API by returning shared_ptr instead of ptr
> > 5e0d3f4 base: fix initialisation of oro_atomic_t
> > 8c99b7f locked: fix major bug in LockedQueue::dequeue function.
>
> That's terrific ! I'll test these patches in the afternoon (and hope it
> will fix the thread-related heap corruption bug). I see you pushed some
> compilation warning fixes. What is the policy regarding 64bits build
> warnings (there are hundreds of them) ?

It's your call. If the compiler warning is utterly crap, disable the warning,
if the warning is about utter crap, fix the crap :-)

Can you give an example of what you're seeing ?

Peter

Important Win32 progress on master branch

On 18/02/2011 09:25, Peter Soetens wrote:
> On Friday 18 February 2011 08:42:35 Jean Sreng wrote:
>> That's terrific ! I'll test these patches in the afternoon (and hope it
>> will fix the thread-related heap corruption bug). I see you pushed some
>> compilation warning fixes. What is the policy regarding 64bits build
>> warnings (there are hundreds of them) ?
>
> It's your call. If the compiler warning is utterly crap, disable the
warning,
> if the warning is about utter crap, fix the crap :-)
>
> Can you give an example of what you're seeing ?

For the vast majority, it's only about conversion between size_t and int
(C4267) and conversion between __int64 and int (C4244). I have also some
C4290 about __declspec(nothow) in the rtt-corba, and other more
anecdotic warnings.

I think the conversion warnings C4267 and C4244 (essentially the use of
.size() and int) can be handled with a #pragma, the other warnings may
be dealt with directly.