RTT and OCL 2.0.0-beta3 released

The third beta release of RTT 2.0 is availabIe from:

http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
http://github.com/psoetens/orocos-rtt
http://github.com/psoetens/orocos-ocl

The main change with beta2 is the plugin framework and the conversion of RTT
marshalling, scripting and typekit into plugins. (see also [1]). The deployer
has been modified to pick the plugins up automatically, and can easily be
extended to find some more. The RTT_COMPONENT_PATH environment variable and
deployer property both list the places where to look for components, plugins
and typekits. The TaskBrowser can be queried for available types and plugins.
A configure() run on the deployer will lead to a re-scan for plugins and
components.

Both the typekit and plugin manuals[3,4] have been updated as well as the 1.x
to 2.0 conversion scripts on the wiki[2]. Please skim the manuals to get an
impression of the API changes for typekits.

Also the TLSF/RT-logging for OCL has been ported from the 1.x line to 2.0, but
this still qualifies as 'experimental'. It also requires a patched version of
log4cpp.

There are no more major changes planned leading to 2.0.0, except that we
wanted the OCL directory structure to be refactored in order to group
components according to maintainer and to cleanup the cmake settings. The RTT
could have some cmake cleanup too. This should have no influence on the API
though.

We're very close to being 'there'. These are the open issues:
* Support event transitions in state machines. Currently, only reacting to new
port data is possible, not the 1.x style multi-argument transition syntax.
* Fix the component lifecycle as discussed earlier on the orocos-dev list.

Both don't require API changes (iirc).

Peter

[1] http://www.orocos.org/forum/rtt/rtt-dev/rtt-2-naming-convention-suggestion
[2] http://www.orocos.org/wiki/rtt/rtt-20/rtt-20-renaming-table
[3] http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/doc/doc-
xml/orocos-typekit-plugin.html
[4] http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/doc/doc-
xml/orocos-rtt-plugins.html

RTT and OCL 2.0.0-beta3 released

Le 28/06/2010 17:12, Peter Soetens a écrit :
> The third beta release of RTT 2.0 is availabIe from:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> http://github.com/psoetens/orocos-rtt
> http://github.com/psoetens/orocos-ocl

Hi, I tried to get this new beta release working under windows. This was
tougher than the previous ones:

* I had to introduce the RTT_MARSH_API, RTT_SCRIPTING_API, etc. in the
same fashion as RTT_CORBA_API to get the DLL dependencies working.
* I removed (temporarily, as said in the comments) the circular
dependency between scripting and rtt. Circular dependencies cannot be
easily handled under win32 because the symbol resolution happens at
compile time, not runtime. This can be a real problem if this circular
dependency is really needed
* I introduced a simple dl* wrapper for the dlopen, dlclose, etc.
functions (from code.google.com/p/dlfcn-win32). This is not
tested/debugged yet
* I made some cmake changes to keep win32 compat. I also specified
different names for Debug and Release DLLs.
* A lot of missing RTT_API and so were added

In the current state, all the libs and tests compiles. Half of the tests
are broken (probably due to non-functional plugin framework under
win32). I'll get to you as soon as this is working.

I hope I did not broke anything on other platforms.

The patches are available on github (branch rtt-2.0-mainline):
http://github.com/jsreng/orocos-rtt

RTT and OCL 2.0.0-beta3 released

Hi Jean,

On Thursday 01 July 2010 18:41:00 Jean Sreng wrote:
> Le 28/06/2010 17:12, Peter Soetens a écrit :
> > The third beta release of RTT 2.0 is availabIe from:
> >
> > http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > http://github.com/psoetens/orocos-rtt
> > http://github.com/psoetens/orocos-ocl
>
> Hi, I tried to get this new beta release working under windows. This was
> tougher than the previous ones:
>
> * I had to introduce the RTT_MARSH_API, RTT_SCRIPTING_API, etc. in the
> same fashion as RTT_CORBA_API to get the DLL dependencies working.

My fault. Since some apps will link against the plugins, they clearly need
these macro's. I hope you had a good multi-file regexp-replace tool at hand !

As far as I know, the typekit plugins don't need this ??

> * I removed (temporarily, as said in the comments) the circular
> dependency between scripting and rtt. Circular dependencies cannot be
> easily handled under win32 because the symbol resolution happens at
> compile time, not runtime. This can be a real problem if this circular
> dependency is really needed

I don't think there is any ? Normally, scripting depends on rtt and not vice
versa. An application like the TaskBrowser depends on scripting and rtt libs.
Are you pointing to a cmake construct ?

> * I introduced a simple dl* wrapper for the dlopen, dlclose, etc.
> functions (from code.google.com/p/dlfcn-win32). This is not
> tested/debugged yet

I was planning to use this one as well. I'll test this too the comming month
(probably after the rtt-dev meeting).

> * I made some cmake changes to keep win32 compat. I also specified
> different names for Debug and Release DLLs.

Thanks !

> * A lot of missing RTT_API and so were added

This was on my todo list :-]

>
> In the current state, all the libs and tests compiles. Half of the tests
> are broken (probably due to non-functional plugin framework under
> win32). I'll get to you as soon as this is working.

Exactly. The unit tests are now very sensitive to finding plugins (just like
any RTT app in the future).

Changes I made to 'help' win32[*]:
* If you don't use a 'build' dir, headers and libs are in the orocos-rtt/rtt
directory, should no longer be necessary to make a copy or do an install on
win32 platforms. I heard once a windows programmer say that the 'make install'
step is often not done on Windows systems. True ?
* Used boost::filesystem in *both* OCL deployer and RTT plugin loading code.
This removes porting of unix style path searching code to win32.

>
> I hope I did not broke anything on other platforms.

I'll merge and test your fixes. How does your branch differ from the patch that
Butch posted a week ago on this list ? Are his and your changes mergeable ?

>
> The patches are available on github (branch rtt-2.0-mainline):
> http://github.com/jsreng/orocos-rtt

Thank you very much. A lot of users are already depending on Windows support
for RTT.

Peter

[*] You might have thought that I was doing the opposite in this release :-)

RTT and OCL 2.0.0-beta3 released

Le 02/07/2010 11:05, Peter Soetens a écrit :
>> * I had to introduce the RTT_MARSH_API, RTT_SCRIPTING_API, etc. in the
>> same fashion as RTT_CORBA_API to get the DLL dependencies working.
>
> My fault. Since some apps will link against the plugins, they clearly need
> these macro's. I hope you had a good multi-file regexp-replace tool at hand !

sed FTW ! (cygwin make the windows world less painful).

> As far as I know, the typekit plugins don't need this ??

I don't know. But as I saw some exported (previously RTT_API) symbols in
some headers of typekit, I assumed that it would be necessary to
similarly sort the import symbols from rtt to the export from typekit.
But maybe this is not necessary because of the plugin nature of typekit ?

>> * I removed (temporarily, as said in the comments) the circular
>> dependency between scripting and rtt. Circular dependencies cannot be
>> easily handled under win32 because the symbol resolution happens at
>> compile time, not runtime. This can be a real problem if this circular
>> dependency is really needed
>
> I don't think there is any ? Normally, scripting depends on rtt and not vice
> versa. An application like the TaskBrowser depends on scripting and rtt libs.
> Are you pointing to a cmake construct ?

There was an #include "scripting/ScriptingService.hpp" that caused some
trouble before I figured out the export/import DLL dependencies. So this
is not a problem anymore (I reverted the commit).

>> * I introduced a simple dl* wrapper for the dlopen, dlclose, etc.
>> functions (from code.google.com/p/dlfcn-win32). This is not
>> tested/debugged yet
>
> I was planning to use this one as well. I'll test this too the comming month
> (probably after the rtt-dev meeting).

After some testing, plugins are nearly working (I messed up the lookup
path in my previous tests). I think however that some tweaking (like for
short names) would be necessary for the framework to be fully functional.

>> In the current state, all the libs and tests compiles. Half of the tests
>> are broken (probably due to non-functional plugin framework under
>> win32). I'll get to you as soon as this is working.
>
> Exactly. The unit tests are now very sensitive to finding plugins (just like
> any RTT app in the future).

Most tests are now nearly working. For instance in the Debug build, only
scripting related tests don't work (the test freeze), and the
type_discovery_test which corrupts the stack. For instance in the corba
test, I can clearly see in the orocos.log that the plugins are correctly
loaded.

However this is another story for the Release build (I think all the
tests relying on plugins fail, even if the orocos.log shows that the
plugins are found and loaded). I'll investigate.

> Changes I made to 'help' win32[*]:
> * If you don't use a 'build' dir, headers and libs are in the orocos-rtt/rtt
> directory, should no longer be necessary to make a copy or do an install on
> win32 platforms. I heard once a windows programmer say that the 'make install'
> step is often not done on Windows systems. True ?

In my case I do the install step (from the Visual Studio IDE, there is a
special target INSTALL). This however does not "deploy" the library
system wide but provides you a convenient and clean directory structure
(like on unices) of what you want to give to developers (headers + doc +
libs).

> I'll merge and test your fixes. How does your branch differ from the patch that
> Butch posted a week ago on this list ? Are his and your changes mergeable ?

I think the fosi.h part is quite equivalent of what is now present in
the rtt-2.0-mainline branch. In Butch's patch, tick and nano differs by
a QueryPerformanceFrequency factor which is not the case in rtt-2.0 . I
remember that I have chosen explicitly to have nano = tick (after some
tests) but I can't remember exactly why.

I think that the fosi_internal.cpp part can be merged. However, we
should really be careful about the timeBeginPeriod and timeEndPeriod
functions (that are used in rtt-2.0 only in timer related functions in a
small scope) as they have system wide consequences.

> Thank you very much. A lot of users are already depending on Windows support
> for RTT.

You're welcome :)

RTT and OCL 2.0.0-beta3 released

Le 02/07/2010 13:54, Jean Sreng a écrit :
> Most tests are now nearly working. For instance in the Debug build, only
> scripting related tests don't work (the test freeze), and the

All the tests involving scripting are freezing because they enter a wait
function that does not catch any event. Particularly:

CallFunction.hpp:78
mrunner->waitForFunctions(boost::bind(&CallFunction::fooDone,this) );

ExecutionEngine.cpp:168
this->waitForMessages( ! lambda::bind(&ExecutableInterface::isLoaded, f)
|| lambda::bind(&RemoveMsg::found,boost::ref(rmsg)) );

It seems in ExecutionEngine that the var cond is signaled before being
caught.

By reverting commit 5da177920a45096370ff960c75d696ac6d478401
(engine: improve waiting for messages and functions.) 26/02/2010 and
commenting the line CallFunction.hpp:78 I managed to get the
program_test working (but unfortunately broke some other that were
working before.

RTT and OCL 2.0.0-beta3 released

On Tue, Jul 6, 2010 at 11:22 AM, Jean Sreng <jean [dot] sreng [..] ...> wrote:
> Le 02/07/2010 13:54, Jean Sreng a écrit :
>> Most tests are now nearly working. For instance in the Debug build, only
>> scripting related tests don't work (the test freeze), and the
>
> All the tests involving scripting are freezing because they enter a wait
> function that does not catch any event. Particularly:
>
> CallFunction.hpp:78
> mrunner->waitForFunctions(boost::bind(&CallFunction::fooDone,this) );
>
> ExecutionEngine.cpp:168
> this->waitForMessages( ! lambda::bind(&ExecutableInterface::isLoaded, f)
> || lambda::bind(&RemoveMsg::found,boost::ref(rmsg)) );
>
> It seems in ExecutionEngine that the var cond is signaled before being
> caught.
>
> By reverting commit 5da177920a45096370ff960c75d696ac6d478401
> (engine: improve waiting for messages and functions.) 26/02/2010 and
> commenting the line CallFunction.hpp:78 I managed to get the
> program_test working (but unfortunately broke some other that were
> working before.

The code is correct, but relies on

1. correct implementation of condition variables. I believe the
boost::thread condition implementation in rtt/os is broken btw. This
is a problem for mac. Maybe windows suffers from this too. It might be
necessary to change the API of os::Condition to resolve this.

2. correct identification of thread id's by rtos_task_is_self(): a
different code path is taken if a foreign thread posts something in
the message queue or the component's own thread is doing so. Deadlock
may happen if this is wrong.

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

Le 06/07/2010 22:08, Peter Soetens a écrit :
> 2. correct identification of thread id's by rtos_task_is_self(): a
> different code path is taken if a foreign thread posts something in
> the message queue or the component's own thread is doing so. Deadlock
> may happen if this is wrong.

I corrected the win32 code on thread Id. And now it's working ! (I
pushed the patches on github).

There is only 3 tests that still don't work:

* Core: It's complaining about:
../../tests/ptr_test.cpp(82): error in "testPromotion": check
!ptr1.valid() failed
../../tests/ptr_test.cpp(100): error in "testPromotion": check
!ptr1.valid() failed

But I don't think it's a big deal.

* Types: I have a segfault somewhere in type_test.cpp:278 and more
particularly in TemplateConstructor.hpp:44 on the new operator (I think
the heap may be corrupted here).

* Function:
../../tests/function_test.cpp(391): fatal error in
"testOnlyExportFunction": Unknown exception thrown by Parser.

--
Jean
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

Le 06/07/2010 22:08, Peter Soetens a écrit :
> 2. correct identification of thread id's by rtos_task_is_self(): a
> different code path is taken if a foreign thread posts something in
> the message queue or the component's own thread is doing so. Deadlock
> may happen if this is wrong.

I corrected the win32 code on thread Id. And now it's working ! (I
pushed the patches on github).

There is only 3 tests that still don't work:

* Core: It's complaining about:
../../tests/ptr_test.cpp(82): error in "testPromotion": check
!ptr1.valid() failed
../../tests/ptr_test.cpp(100): error in "testPromotion": check
!ptr1.valid() failed

But I don't think it's a big deal.

* Types: I have a segfault somewhere in type_test.cpp:278 and more
particularly in TemplateConstructor.hpp:44 on the new operator (I think
the heap may be corrupted here).

* Function:
../../tests/function_test.cpp(391): fatal error in
"testOnlyExportFunction": Unknown exception thrown by Parser.

--
Jean
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

On Friday 02 July 2010 13:54:28 Jean Sreng wrote:
> Le 02/07/2010 11:05, Peter Soetens a écrit :
...
> >> * I removed (temporarily, as said in the comments) the circular
> >> dependency between scripting and rtt. Circular dependencies cannot be
> >> easily handled under win32 because the symbol resolution happens at
> >> compile time, not runtime. This can be a real problem if this circular
> >> dependency is really needed
> >
> > I don't think there is any ? Normally, scripting depends on rtt and not
> > vice versa. An application like the TaskBrowser depends on scripting and
> > rtt libs. Are you pointing to a cmake construct ?
>
> There was an #include "scripting/ScriptingService.hpp" that caused some
> trouble before I figured out the export/import DLL dependencies. So this
> is not a problem anymore (I reverted the commit).

Ok. We could still remove that line, since it's not needed. Users need to
#include <rtt/scripting/Scripting.hpp> anyway instead of
ScriptingService.hpp...
Same for marshalling. I would vote to remove both.

>
> >> * I introduced a simple dl* wrapper for the dlopen, dlclose, etc.
> >> functions (from code.google.com/p/dlfcn-win32). This is not
> >> tested/debugged yet
> >
> > I was planning to use this one as well. I'll test this too the comming
> > month (probably after the rtt-dev meeting).
>
> After some testing, plugins are nearly working (I messed up the lookup
> path in my previous tests). I think however that some tweaking (like for
> short names) would be necessary for the framework to be fully functional.

Short as in short filenames or short plugin names (getName()) ?

>
> >> In the current state, all the libs and tests compiles. Half of the tests
> >> are broken (probably due to non-functional plugin framework under
> >> win32). I'll get to you as soon as this is working.
> >
> > Exactly. The unit tests are now very sensitive to finding plugins (just
> > like any RTT app in the future).
>
> Most tests are now nearly working. For instance in the Debug build, only
> scripting related tests don't work (the test freeze), and the
> type_discovery_test which corrupts the stack. For instance in the corba
> test, I can clearly see in the orocos.log that the plugins are correctly
> loaded.

grr. type_discovery_test tests the part that scripting needs very badly. Both
bugs are most likely related. So try first to take a look at type_discovery. It
uses some functions from boost::serialization too.

>
> However this is another story for the Release build (I think all the
> tests relying on plugins fail, even if the orocos.log shows that the
> plugins are found and loaded). I'll investigate.

I have another report of Release builds not behaving on windows. Something
with too long filenames in scripting (see
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=767 ).

Peter

RTT and OCL 2.0.0-beta3 released

On Jul 2, 2010, at 05:05 , Peter Soetens wrote:

> Hi Jean,
>
> On Thursday 01 July 2010 18:41:00 Jean Sreng wrote:
>> Le 28/06/2010 17:12, Peter Soetens a écrit :
>>> The third beta release of RTT 2.0 is availabIe from:
>>>
>>> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
>>> http://github.com/psoetens/orocos-rtt
>>> http://github.com/psoetens/orocos-ocl

<snip>

>> In the current state, all the libs and tests compiles. Half of the tests
>> are broken (probably due to non-functional plugin framework under
>> win32). I'll get to you as soon as this is working.
>
> Exactly. The unit tests are now very sensitive to finding plugins (just like
> any RTT app in the future).

I haven't hit this myself yet, but a few of you have referenced this. Can someone explain in more detail what the problem is, or is going to be?
S

RTT and OCL 2.0.0-beta3 released

Will the component descriptor creation by the deployment tool be part
of the release?

-H

[Orocos] RTT and OCL 2.0.0-beta3 released

On Jun 28, 2010, at 11:12 , Peter Soetens wrote:

> The third beta release of RTT 2.0 is availabIe from:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> http://github.com/psoetens/orocos-rtt
> http://github.com/psoetens/orocos-ocl
>
> The main change with beta2 is the plugin framework and the conversion of RTT
> marshalling, scripting and typekit into plugins. (see also [1]). The deployer
> has been modified to pick the plugins up automatically, and can easily be
> extended to find some more. The RTT_COMPONENT_PATH environment variable and
> deployer property both list the places where to look for components, plugins
> and typekits. The TaskBrowser can be queried for available types and plugins.
> A configure() run on the deployer will lead to a re-scan for plugins and
> components.
>
> Both the typekit and plugin manuals[3,4] have been updated as well as the 1.x
> to 2.0 conversion scripts on the wiki[2]. Please skim the manuals to get an
> impression of the API changes for typekits.
>
> Also the TLSF/RT-logging for OCL has been ported from the 1.x line to 2.0, but
> this still qualifies as 'experimental'. It also requires a patched version of
> log4cpp.
>
> There are no more major changes planned leading to 2.0.0, except that we
> wanted the OCL directory structure to be refactored in order to group
> components according to maintainer and to cleanup the cmake settings. The RTT
> could have some cmake cleanup too. This should have no influence on the API
> though.
>
> We're very close to being 'there'. These are the open issues:
> * Support event transitions in state machines. Currently, only reacting to new
> port data is possible, not the 1.x style multi-argument transition syntax.
> * Fix the component lifecycle as discussed earlier on the orocos-dev list.
>
> Both don't require API changes (iirc).
>
> Peter

OCL patches for Ubuntu Lynx 10.04 attached.

Still no joy on Mac OS X for RTT. I'll take another look and see if I can figure out some Boost magic to get it to build.
S

[Orocos] RTT and OCL 2.0.0-beta3 released

On Jun 28, 2010, at 11:12 , Peter Soetens wrote:

> The third beta release of RTT 2.0 is availabIe from:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> http://github.com/psoetens/orocos-rtt
> http://github.com/psoetens/orocos-ocl
>
> The main change with beta2 is the plugin framework and the conversion of RTT
> marshalling, scripting and typekit into plugins. (see also [1]). The deployer
> has been modified to pick the plugins up automatically, and can easily be
> extended to find some more. The RTT_COMPONENT_PATH environment variable and
> deployer property both list the places where to look for components, plugins
> and typekits. The TaskBrowser can be queried for available types and plugins.
> A configure() run on the deployer will lead to a re-scan for plugins and
> components.
>
> Both the typekit and plugin manuals[3,4] have been updated as well as the 1.x
> to 2.0 conversion scripts on the wiki[2]. Please skim the manuals to get an
> impression of the API changes for typekits.
>
> Also the TLSF/RT-logging for OCL has been ported from the 1.x line to 2.0, but
> this still qualifies as 'experimental'. It also requires a patched version of
> log4cpp.
>
> There are no more major changes planned leading to 2.0.0, except that we
> wanted the OCL directory structure to be refactored in order to group
> components according to maintainer and to cleanup the cmake settings. The RTT
> could have some cmake cleanup too. This should have no influence on the API
> though.
>
> We're very close to being 'there'. These are the open issues:
> * Support event transitions in state machines. Currently, only reacting to new
> port data is possible, not the 1.x style multi-argument transition syntax.
> * Fix the component lifecycle as discussed earlier on the orocos-dev list.
>
> Both don't require API changes (iirc).
>
> Peter

OCL patches for Ubuntu Lynx 10.04 attached.

Still no joy on Mac OS X for RTT. I'll take another look and see if I can figure out some Boost magic to get it to build.
S

[Orocos] RTT and OCL 2.0.0-beta3 released

On Tuesday 29 June 2010 14:50:04 S Roderick wrote:
> On Jun 28, 2010, at 11:12 , Peter Soetens wrote:
> > The third beta release of RTT 2.0 is availabIe from:
> >
> > http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > http://github.com/psoetens/orocos-rtt
> > http://github.com/psoetens/orocos-ocl
> >
> > The main change with beta2 is the plugin framework and the conversion of
> > RTT marshalling, scripting and typekit into plugins. (see also [1]). The
> > deployer has been modified to pick the plugins up automatically, and can
> > easily be extended to find some more. The RTT_COMPONENT_PATH environment
> > variable and deployer property both list the places where to look for
> > components, plugins and typekits. The TaskBrowser can be queried for
> > available types and plugins. A configure() run on the deployer will lead
> > to a re-scan for plugins and components.
> >
> > Both the typekit and plugin manuals[3,4] have been updated as well as the
> > 1.x to 2.0 conversion scripts on the wiki[2]. Please skim the manuals to
> > get an impression of the API changes for typekits.
> >
> > Also the TLSF/RT-logging for OCL has been ported from the 1.x line to
> > 2.0, but this still qualifies as 'experimental'. It also requires a
> > patched version of log4cpp.
> >
> > There are no more major changes planned leading to 2.0.0, except that we
> > wanted the OCL directory structure to be refactored in order to group
> > components according to maintainer and to cleanup the cmake settings. The
> > RTT could have some cmake cleanup too. This should have no influence on
> > the API though.
> >
> > We're very close to being 'there'. These are the open issues:
> > * Support event transitions in state machines. Currently, only reacting
> > to new port data is possible, not the 1.x style multi-argument transition
> > syntax. * Fix the component lifecycle as discussed earlier on the
> > orocos-dev list.
> >
> > Both don't require API changes (iirc).
> >
> > Peter
>
> OCL patches for Ubuntu Lynx 10.04 attached.

Thanks, applied.

>
> Still no joy on Mac OS X for RTT. I'll take another look and see if I can
> figure out some Boost magic to get it to build. S

Don't hesitate to throw the build errors on the list...

Peter

[Orocos] RTT and OCL 2.0.0-beta3 released

On Jun 29, 2010, at 09:53 , Peter Soetens wrote:

> On Tuesday 29 June 2010 14:50:04 S Roderick wrote:
>> On Jun 28, 2010, at 11:12 , Peter Soetens wrote:
>>> The third beta release of RTT 2.0 is availabIe from:
>>>
>>> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
>>> http://github.com/psoetens/orocos-rtt
>>> http://github.com/psoetens/orocos-ocl
>>>
>>> The main change with beta2 is the plugin framework and the conversion of
>>> RTT marshalling, scripting and typekit into plugins. (see also [1]). The
>>> deployer has been modified to pick the plugins up automatically, and can
>>> easily be extended to find some more. The RTT_COMPONENT_PATH environment
>>> variable and deployer property both list the places where to look for
>>> components, plugins and typekits. The TaskBrowser can be queried for
>>> available types and plugins. A configure() run on the deployer will lead
>>> to a re-scan for plugins and components.
>>>
>>> Both the typekit and plugin manuals[3,4] have been updated as well as the
>>> 1.x to 2.0 conversion scripts on the wiki[2]. Please skim the manuals to
>>> get an impression of the API changes for typekits.
>>>
>>> Also the TLSF/RT-logging for OCL has been ported from the 1.x line to
>>> 2.0, but this still qualifies as 'experimental'. It also requires a
>>> patched version of log4cpp.
>>>
>>> There are no more major changes planned leading to 2.0.0, except that we
>>> wanted the OCL directory structure to be refactored in order to group
>>> components according to maintainer and to cleanup the cmake settings. The
>>> RTT could have some cmake cleanup too. This should have no influence on
>>> the API though.
>>>
>>> We're very close to being 'there'. These are the open issues:
>>> * Support event transitions in state machines. Currently, only reacting
>>> to new port data is possible, not the 1.x style multi-argument transition
>>> syntax. * Fix the component lifecycle as discussed earlier on the
>>> orocos-dev list.
>>>
>>> Both don't require API changes (iirc).
>>>
>>> Peter
>>
>> OCL patches for Ubuntu Lynx 10.04 attached.
>
> Thanks, applied.
>
>>
>> Still no joy on Mac OS X for RTT. I'll take another look and see if I can
>> figure out some Boost magic to get it to build. S
>
> Don't hesitate to throw the build errors on the list...

I did that previously ... and no one listened ... ;-)

It's that we are using timex_mutex and the functions we are calling only take plain mutex types. I poked around in the boost doc's, but didn't get far.
S

sroderick@mp rtt $ make
[ 1%] Building CXX object rtt/CMakeFiles/orocos-rtt-dynamic_macosx.dir/ExecutionEngine.cpp.o
In file included from /g/o/rtt/rtt/ExecutionEngine.hpp:44,
from /g/o/rtt/rtt/ExecutionEngine.cpp:41:
/g/o/rtt/rtt/os/Condition.hpp: In member function ‘bool RTT::os::Condition::wait(RTT::os::Mutex&)’:
/g/o/rtt/rtt/os/Condition.hpp:125: error: no matching function for call to ‘boost::condition_variable::wait(boost::timed_mutex&)’
/opt/local/include/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&)
/g/o/rtt/rtt/os/Condition.hpp: In member function ‘bool RTT::os::Condition::wait_until(RTT::os::Mutex&, RTT::nsecs)’:
/g/o/rtt/rtt/os/Condition.hpp:166: error: ‘nanoseconds’ was not declared in this scope
/g/o/rtt/rtt/os/Condition.hpp:169: error: no matching function for call to ‘boost::condition_variable::timed_wait(RTT::os::Mutex&, boost::posix_time::ptime&, bool)’
/opt/local/include/boost/thread/pthread/condition_variable.hpp:23: note: candidates are: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::system_time&)
/opt/local/include/boost/thread/pthread/condition_variable_fwd.hpp:50: note: bool boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, const boost::xtime&)
make[2]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_macosx.dir/ExecutionEngine.cpp.o] Error 1
make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_macosx.dir/all] Error 2
make: *** [all] Error 2

[Orocos] RTT and OCL 2.0.0-beta3 released

On Tuesday 29 June 2010 15:58:10 Stephen Roderick wrote:
> On Jun 29, 2010, at 09:53 , Peter Soetens wrote:
> > On Tuesday 29 June 2010 14:50:04 S Roderick wrote:
> >> On Jun 28, 2010, at 11:12 , Peter Soetens wrote:
> >>> The third beta release of RTT 2.0 is availabIe from:
> >>>
> >>> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> >>> http://github.com/psoetens/orocos-rtt
> >>> http://github.com/psoetens/orocos-ocl
> >>>
> >>> The main change with beta2 is the plugin framework and the conversion
> >>> of RTT marshalling, scripting and typekit into plugins. (see also [1]).
> >>> The deployer has been modified to pick the plugins up automatically,
> >>> and can easily be extended to find some more. The RTT_COMPONENT_PATH
> >>> environment variable and deployer property both list the places where
> >>> to look for components, plugins and typekits. The TaskBrowser can be
> >>> queried for available types and plugins. A configure() run on the
> >>> deployer will lead to a re-scan for plugins and components.
> >>>
> >>> Both the typekit and plugin manuals[3,4] have been updated as well as
> >>> the 1.x to 2.0 conversion scripts on the wiki[2]. Please skim the
> >>> manuals to get an impression of the API changes for typekits.
> >>>
> >>> Also the TLSF/RT-logging for OCL has been ported from the 1.x line to
> >>> 2.0, but this still qualifies as 'experimental'. It also requires a
> >>> patched version of log4cpp.
> >>>
> >>> There are no more major changes planned leading to 2.0.0, except that
> >>> we wanted the OCL directory structure to be refactored in order to
> >>> group components according to maintainer and to cleanup the cmake
> >>> settings. The RTT could have some cmake cleanup too. This should have
> >>> no influence on the API though.
> >>>
> >>> We're very close to being 'there'. These are the open issues:
> >>> * Support event transitions in state machines. Currently, only reacting
> >>> to new port data is possible, not the 1.x style multi-argument
> >>> transition syntax. * Fix the component lifecycle as discussed earlier
> >>> on the orocos-dev list.
> >>>
> >>> Both don't require API changes (iirc).
> >>>
> >>> Peter
> >>
> >> OCL patches for Ubuntu Lynx 10.04 attached.
> >
> > Thanks, applied.
> >
> >> Still no joy on Mac OS X for RTT. I'll take another look and see if I
> >> can figure out some Boost magic to get it to build. S
> >
> > Don't hesitate to throw the build errors on the list...
>
> I did that previously ... and no one listened ... ;-)
>
> It's that we are using timex_mutex and the functions we are calling only
> take plain mutex types. I poked around in the boost doc's, but didn't get
> far. S

Could reproduce this on gnulinux. The patch in attachment seems to do it,
although the less performant 'condition_variable_any' implementation of boost
had to be used. If this works for you,I'll push it to the mainline.

WorksForMe (tm)

Peter

[Orocos] RTT and OCL 2.0.0-beta3 released

On Tuesday 29 June 2010 16:50:13 Peter Soetens wrote:
> On Tuesday 29 June 2010 15:58:10 Stephen Roderick wrote:
> > On Jun 29, 2010, at 09:53 , Peter Soetens wrote:
> > > On Tuesday 29 June 2010 14:50:04 S Roderick wrote:
> > >> On Jun 28, 2010, at 11:12 , Peter Soetens wrote:
> > >>> The third beta release of RTT 2.0 is availabIe from:
> > >>>
> > >>> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > >>> http://github.com/psoetens/orocos-rtt
> > >>> http://github.com/psoetens/orocos-ocl
> > >>>
> > >>> The main change with beta2 is the plugin framework and the conversion
> > >>> of RTT marshalling, scripting and typekit into plugins. (see also
> > >>> [1]). The deployer has been modified to pick the plugins up
> > >>> automatically, and can easily be extended to find some more. The
> > >>> RTT_COMPONENT_PATH environment variable and deployer property both
> > >>> list the places where to look for components, plugins and typekits.
> > >>> The TaskBrowser can be queried for available types and plugins. A
> > >>> configure() run on the deployer will lead to a re-scan for plugins
> > >>> and components.
> > >>>
> > >>> Both the typekit and plugin manuals[3,4] have been updated as well as
> > >>> the 1.x to 2.0 conversion scripts on the wiki[2]. Please skim the
> > >>> manuals to get an impression of the API changes for typekits.
> > >>>
> > >>> Also the TLSF/RT-logging for OCL has been ported from the 1.x line to
> > >>> 2.0, but this still qualifies as 'experimental'. It also requires a
> > >>> patched version of log4cpp.
> > >>>
> > >>> There are no more major changes planned leading to 2.0.0, except that
> > >>> we wanted the OCL directory structure to be refactored in order to
> > >>> group components according to maintainer and to cleanup the cmake
> > >>> settings. The RTT could have some cmake cleanup too. This should have
> > >>> no influence on the API though.
> > >>>
> > >>> We're very close to being 'there'. These are the open issues:
> > >>> * Support event transitions in state machines. Currently, only
> > >>> reacting to new port data is possible, not the 1.x style
> > >>> multi-argument transition syntax. * Fix the component lifecycle as
> > >>> discussed earlier on the orocos-dev list.
> > >>>
> > >>> Both don't require API changes (iirc).
> > >>>
> > >>> Peter
> > >>
> > >> OCL patches for Ubuntu Lynx 10.04 attached.
> > >
> > > Thanks, applied.
> > >
> > >> Still no joy on Mac OS X for RTT. I'll take another look and see if I
> > >> can figure out some Boost magic to get it to build. S
> > >
> > > Don't hesitate to throw the build errors on the list...
> >
> > I did that previously ... and no one listened ... ;-)
> >
> > It's that we are using timex_mutex and the functions we are calling only
> > take plain mutex types. I poked around in the boost doc's, but didn't
> > get far. S
>
> Could reproduce this on gnulinux. The patch in attachment seems to do it,
> although the less performant 'condition_variable_any' implementation of
> boost had to be used. If this works for you,I'll push it to the mainline.
>
> WorksForMe (tm)

One typo in this patch: it forces ORO_OS_USE_BOOST_THREAD on top of
Condition.hpp. Needs to be removed or won't build on non-boost configurations.

Peter

[Orocos] RTT and OCL 2.0.0-beta3 released

On Jun 29, 2010, at 11:27 , Peter Soetens wrote:

> On Tuesday 29 June 2010 16:50:13 Peter Soetens wrote:
>> On Tuesday 29 June 2010 15:58:10 Stephen Roderick wrote:
>>> On Jun 29, 2010, at 09:53 , Peter Soetens wrote:
>>>> On Tuesday 29 June 2010 14:50:04 S Roderick wrote:
>>>>> On Jun 28, 2010, at 11:12 , Peter Soetens wrote:
>>>>>> The third beta release of RTT 2.0 is availabIe from:

<snip>

Your previous two patches helped. Thanks.

Now the below. BlockingPolicy::reset() is conditionally compiled out for Mac OS X, presumably as semaphores aren't countable.
S

&#10;[  0%] Building CXX object rtt/CMakeFiles/orocos-rtt-dynamic_macosx.dir/extras/EventDrivenActivity.cpp.o&#10;/g/o/rtt/rtt/extras/../base/../internal/AtomicQueue.hpp: In member function ‘void RTT::internal::AtomicQueue&lt;T, ReadPolicy, WritePolicy&gt;::clear() [with T = RTT::internal::Signal&lt;void ()(), boost::function&lt;void ()()&gt; &gt;**, ReadPolicy = RTT::base::BlockingPolicy, WritePolicy = RTT::base::NonBlockingPolicy]’:&#10;/g/o/rtt/rtt/extras/../base/../internal/AtomicQueue.hpp:160:   instantiated from ‘RTT::internal::AtomicQueue&lt;T, ReadPolicy, WritePolicy&gt;::AtomicQueue(unsigned int) [with T = RTT::internal::Signal&lt;void ()(), boost::function&lt;void ()()&gt; &gt;**, ReadPolicy = RTT::base::BlockingPolicy, WritePolicy = RTT::base::NonBlockingPolicy]’&#10;/g/o/rtt/rtt/extras/../base/BufferLockFree.hpp:96:   instantiated from ‘RTT::base::BufferLockFree&lt;T, ReadPolicy, WritePolicy&gt;::BufferLockFree(unsigned int, const T&amp;) [with T = RTT::internal::Signal&lt;void ()(), boost::function&lt;void ()()&gt; &gt;*, ReadPolicy = RTT::base::BlockingPolicy, WritePolicy = RTT::base::NonBlockingPolicy]’&#10;/g/o/rtt/rtt/extras/../base/Buffer.hpp:88:   instantiated from ‘RTT::base::Buffer&lt;T, ReadPolicy, WritePolicy&gt;::Buffer(int, const T&amp;) [with T = RTT::internal::Signal&lt;void ()(), boost::function&lt;void ()()&gt; &gt;*, ReadPolicy = RTT::base::BlockingPolicy, WritePolicy = RTT::base::NonBlockingPolicy]’&#10;/g/o/rtt/rtt/extras/EventDrivenActivity.cpp:78:   instantiated from here&#10;/g/o/rtt/rtt/extras/../base/../internal/AtomicQueue.hpp:300: error: ‘struct RTT::base::BlockingPolicy’ has no member named ‘reset’&#10;make[2]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_macosx.dir/extras/EventDrivenActivity.cpp.o] Error 1&#10;make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_macosx.dir/all] Error 2&#10;make: *** [all] Error 2&#10;

[Orocos] RTT and OCL 2.0.0-beta3 released

On Wednesday 30 June 2010 01:52:18 Stephen Roderick wrote:
> On Jun 29, 2010, at 11:27 , Peter Soetens wrote:
> > On Tuesday 29 June 2010 16:50:13 Peter Soetens wrote:
> >> On Tuesday 29 June 2010 15:58:10 Stephen Roderick wrote:
> >>> On Jun 29, 2010, at 09:53 , Peter Soetens wrote:
> >>>> On Tuesday 29 June 2010 14:50:04 S Roderick wrote:
> >>>>> On Jun 28, 2010, at 11:12 , Peter Soetens wrote:
> >>>>>> The third beta release of RTT 2.0 is availabIe from:
>
> <snip>
>
> Your previous two patches helped. Thanks.
>
> Now the below. BlockingPolicy::reset() is conditionally compiled out for
> Mac OS X, presumably as semaphores aren't countable. S

That's strange. The BlockingPolicy should be gone in 2.0 :-) It seems a part
of the AtomicQueue rework I've done has not made its way into the mainline.

I propose to remove EventDrivenActivity from the mainline, it probably doesn't
work / won't work anytime soon.

Peter

[Orocos] RTT and OCL 2.0.0-beta3 released

On Jun 28, 2010, at 11:12 , Peter Soetens wrote:

> The third beta release of RTT 2.0 is availabIe from:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> http://github.com/psoetens/orocos-rtt
> http://github.com/psoetens/orocos-ocl
>
> The main change with beta2 is the plugin framework and the conversion of RTT
> marshalling, scripting and typekit into plugins. (see also [1]). The deployer
> has been modified to pick the plugins up automatically, and can easily be
> extended to find some more. The RTT_COMPONENT_PATH environment variable and
> deployer property both list the places where to look for components, plugins
> and typekits. The TaskBrowser can be queried for available types and plugins.
> A configure() run on the deployer will lead to a re-scan for plugins and
> components.
>
> Both the typekit and plugin manuals[3,4] have been updated as well as the 1.x
> to 2.0 conversion scripts on the wiki[2]. Please skim the manuals to get an
> impression of the API changes for typekits.
>
> Also the TLSF/RT-logging for OCL has been ported from the 1.x line to 2.0, but
> this still qualifies as 'experimental'. It also requires a patched version of
> log4cpp.
>
> There are no more major changes planned leading to 2.0.0, except that we
> wanted the OCL directory structure to be refactored in order to group
> components according to maintainer and to cleanup the cmake settings. The RTT
> could have some cmake cleanup too. This should have no influence on the API
> though.
>
> We're very close to being 'there'. These are the open issues:
> * Support event transitions in state machines. Currently, only reacting to new
> port data is possible, not the 1.x style multi-argument transition syntax.
> * Fix the component lifecycle as discussed earlier on the orocos-dev list.
>
> Both don't require API changes (iirc).
>
> Peter

Also, what are the plans of the KDL and BFL maintainers for porting their plugins to RTT v2?
Stephen

[Orocos] RTT and OCL 2.0.0-beta3 released

On Jun 28, 2010, at 11:12 , Peter Soetens wrote:

> The third beta release of RTT 2.0 is availabIe from:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> http://github.com/psoetens/orocos-rtt
> http://github.com/psoetens/orocos-ocl
>
> The main change with beta2 is the plugin framework and the conversion of RTT
> marshalling, scripting and typekit into plugins. (see also [1]). The deployer
> has been modified to pick the plugins up automatically, and can easily be
> extended to find some more. The RTT_COMPONENT_PATH environment variable and
> deployer property both list the places where to look for components, plugins
> and typekits. The TaskBrowser can be queried for available types and plugins.
> A configure() run on the deployer will lead to a re-scan for plugins and
> components.
>
> Both the typekit and plugin manuals[3,4] have been updated as well as the 1.x
> to 2.0 conversion scripts on the wiki[2]. Please skim the manuals to get an
> impression of the API changes for typekits.
>
> Also the TLSF/RT-logging for OCL has been ported from the 1.x line to 2.0, but
> this still qualifies as 'experimental'. It also requires a patched version of
> log4cpp.
>
> There are no more major changes planned leading to 2.0.0, except that we
> wanted the OCL directory structure to be refactored in order to group
> components according to maintainer and to cleanup the cmake settings. The RTT
> could have some cmake cleanup too. This should have no influence on the API
> though.
>
> We're very close to being 'there'. These are the open issues:
> * Support event transitions in state machines. Currently, only reacting to new
> port data is possible, not the 1.x style multi-argument transition syntax.
> * Fix the component lifecycle as discussed earlier on the orocos-dev list.
>
> Both don't require API changes (iirc).
>
> Peter

Also, what are the plans of the KDL and BFL maintainers for porting their plugins to RTT v2?
Stephen

[Orocos] RTT and OCL 2.0.0-beta3 released

> Also, what are the plans of the KDL and BFL maintainers for porting their plugins to RTT v2?

I plan to port BFL in second half of August.

Tinne

> Stephen

[Orocos] RTT and OCL 2.0.0-beta3 released

> Also, what are the plans of the KDL and BFL maintainers for porting their plugins to RTT v2?

I plan to port BFL in second half of August.

Tinne

> Stephen

RTT and OCL 2.0.0-beta3 released

A Dilluns 28 Juny 2010, Peter Soetens va escriure:
> The third beta release of RTT 2.0 is availabIe from:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> http://github.com/psoetens/orocos-rtt
> http://github.com/psoetens/orocos-ocl

the current git head fails to compile in the files below. I'm using boost
1.42.

Leo

In file included
from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,

from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In member
function ‘void RTT::types::type_discovery::discover(T&)’:
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
wrong number of template arguments (2, should be 1)
/usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
for ‘template<class Archive> struct
boost::archive::detail::load_non_pointer_type’
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
error: ‘load_only’ has not been declared
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
invalid type in declaration before ‘(’ token
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
invalid use of qualified-name ‘<declaration error>::invoke’
make[2]: ***
[rtt/CMakeFiles/orocos-rtt-static_gnulinux.dir/types/SequenceTypeInfo.cpp.o]
Error 1
make[1]: *** [rtt/CMakeFiles/orocos-rtt-static_gnulinux.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 30%] Building CXX object
rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/TypekitRepository.cpp.o
In file included
from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,

from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In member
function ‘void RTT::types::type_discovery::discover(T&)’:
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
wrong number of template arguments (2, should be 1)
/usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
for ‘template<class Archive> struct
boost::archive::detail::load_non_pointer_type’
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
error: ‘load_only’ has not been declared
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
invalid type in declaration before ‘(’ token
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
invalid use of qualified-name ‘<declaration error>::invoke’
make[2]: ***
[rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/SequenceTypeInfo.cpp.o]
Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
make: *** [all] Error 2
leo@leonidas:~/robotica/orocos/orocos-git/build$
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

On Monday 28 June 2010 17:12:14 Peter Soetens wrote:
>
> We're very close to being 'there'. These are the open issues:
> * Support event transitions in state machines. Currently, only reacting to
> new port data is possible, not the 1.x style multi-argument transition
> syntax.

I implemented this and pushed it to the 2.0 mainline. The idea is that when
you wrote in 1.x:

&#10;RTT::Event&lt;void(int,int,int)&gt; myEvent(&quot;event&quot;);&#10;this-&gt;events()-&gt;addEvent( &amp;myEvent );&#10;
The rtt2-conversion script (To Be Done) would port this to 2.x as:
&#10;RTT::Operation&lt;void(int,int,int)&gt; myEvent(&quot;event&quot;);&#10;this-&gt;provides()-&gt;addOperation( myEvent );&#10;

The syntax in your SM script remains identical:
&#10;  transition event(a,b,c) select next_state; // event is operation in current &#10;component&#10;

You'd emit the event by calling that operation, possibly from another
TaskContext (ie distributed!) or from your local C++ code. This mechanism does
not exclude the 'normal' use of the operation.

However, your SM script can only make a transition from 'events' of its own
TaskContext, ie, you can not write:

&#10; transition peer.foo(a,b,c) select next_state; // can not react to peer&#039;s &#10;operation&#10;

Also, the operation needs to be of OwnThread type in order to be usable as
event transition in scripting. This is because the event is emitted in the
thread that also calls the operation's function. The state machine's callback
code is not thread-safe, so it must be called from the component's thread, ie
OwnThread.

> * Fix the component lifecycle as discussed earlier on the
> orocos-dev list.

Is next on my agenda. Maybe also to add:

* Provide InputPort<void> OutputPort<void> implementations in case you want to
broadcast a data-less event. Could be after 2.0.0.
* Fix the compile time regression. Could also be fixed after 2.0.0
* Provide code generator for mqueue / typekits (non CORBA types and
transports) based on ROS .msg formats. Could also be after 2.0.0.

Peter

RTT and OCL 2.0.0-beta3 released

On Monday 28 June 2010 17:12:14 Peter Soetens wrote:
>
> We're very close to being 'there'. These are the open issues:
> * Support event transitions in state machines. Currently, only reacting to
> new port data is possible, not the 1.x style multi-argument transition
> syntax.

I implemented this and pushed it to the 2.0 mainline. The idea is that when
you wrote in 1.x:

&#10;RTT::Event&lt;void(int,int,int)&gt; myEvent(&quot;event&quot;);&#10;this-&gt;events()-&gt;addEvent( &amp;myEvent );&#10;
The rtt2-conversion script (To Be Done) would port this to 2.x as:
&#10;RTT::Operation&lt;void(int,int,int)&gt; myEvent(&quot;event&quot;);&#10;this-&gt;provides()-&gt;addOperation( myEvent );&#10;

The syntax in your SM script remains identical:
&#10;  transition event(a,b,c) select next_state; // event is operation in current &#10;component&#10;

You'd emit the event by calling that operation, possibly from another
TaskContext (ie distributed!) or from your local C++ code. This mechanism does
not exclude the 'normal' use of the operation.

However, your SM script can only make a transition from 'events' of its own
TaskContext, ie, you can not write:

&#10; transition peer.foo(a,b,c) select next_state; // can not react to peer&#039;s &#10;operation&#10;

Also, the operation needs to be of OwnThread type in order to be usable as
event transition in scripting. This is because the event is emitted in the
thread that also calls the operation's function. The state machine's callback
code is not thread-safe, so it must be called from the component's thread, ie
OwnThread.

> * Fix the component lifecycle as discussed earlier on the
> orocos-dev list.

Is next on my agenda. Maybe also to add:

* Provide InputPort<void> OutputPort<void> implementations in case you want to
broadcast a data-less event. Could be after 2.0.0.
* Fix the compile time regression. Could also be fixed after 2.0.0
* Provide code generator for mqueue / typekits (non CORBA types and
transports) based on ROS .msg formats. Could also be after 2.0.0.

Peter

RTT and OCL 2.0.0-beta3 released

A Dilluns 28 Juny 2010, Peter Soetens va escriure:
> The third beta release of RTT 2.0 is availabIe from:
>
> http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> http://github.com/psoetens/orocos-rtt
> http://github.com/psoetens/orocos-ocl

also, fails here, after the Peter's update.

In file included
from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,

from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In member
function ‘void RTT::types::type_discovery::discover(T&)’:
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
wrong number of template arguments (2, should be 1)
/usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
for ‘template<class Archive> struct
boost::archive::detail::load_non_pointer_type’
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
error: ‘load_only’ has not been declared
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
invalid type in declaration before ‘(’ token
/home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
invalid use of qualified-name ‘<declaration error>::invoke’
make[2]: ***
[rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/SequenceTypeInfo.cpp.o]
Error 1
make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2

Leo
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

On Tue, Jun 29, 2010 at 01:00:47PM +0200, Leopold Palomo-Avellaneda wrote:
> A Dilluns 28 Juny 2010, Peter Soetens va escriure:
> > The third beta release of RTT 2.0 is availabIe from:
> >
> > http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > http://github.com/psoetens/orocos-rtt
> > http://github.com/psoetens/orocos-ocl
>
>
> also, fails here, after the Peter's update.
>
>
> In file included
> from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,
>
> from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In member
> function ‘void RTT::types::type_discovery::discover(T&)’:
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
> wrong number of template arguments (2, should be 1)
> /usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
> for ‘template<class Archive> struct
> boost::archive::detail::load_non_pointer_type’
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> error: ‘load_only’ has not been declared
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
> invalid type in declaration before ‘(’ token
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109: error:
> invalid use of qualified-name ‘<declaration error>::invoke’
> make[2]: ***
> [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/SequenceTypeInfo.cpp.o]
> Error 1
> make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2

I can confirm this one (with boost 1.42).

Markus
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

On Tuesday 29 June 2010 16:36:03 Markus Klotzbuecher wrote:
> On Tue, Jun 29, 2010 at 01:00:47PM +0200, Leopold Palomo-Avellaneda wrote:
> > A Dilluns 28 Juny 2010, Peter Soetens va escriure:
> > > The third beta release of RTT 2.0 is availabIe from:
> > >
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > > http://github.com/psoetens/orocos-rtt
> > > http://github.com/psoetens/orocos-ocl
> >
> > also, fails here, after the Peter's update.
> >
> >
> > In file included
> > from
> > /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,
> >
> > from
> > /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In
> > member function ‘void RTT::types::type_discovery::discover(T&)’:
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: wrong number of template arguments (2, should be 1)
> > /usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
> > for ‘template<class Archive> struct
> > boost::archive::detail::load_non_pointer_type’
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: ‘load_only’ has not been declared
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: invalid type in declaration before ‘(’ token
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: invalid use of qualified-name ‘<declaration error>::invoke’
> > make[2]: ***
> > [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/SequenceTypeInfo.cp
> >p.o] Error 1
> > make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
>
> I can confirm this one (with boost 1.42).

Yep, seen this before. The patch in attachment fixes this. I'll push it to
github.

Peter

RTT and OCL 2.0.0-beta3 released

On Tue, Jun 29, 2010 at 04:58:27PM +0200, Peter Soetens wrote:
> On Tuesday 29 June 2010 16:36:03 Markus Klotzbuecher wrote:
> > On Tue, Jun 29, 2010 at 01:00:47PM +0200, Leopold Palomo-Avellaneda wrote:
> > > A Dilluns 28 Juny 2010, Peter Soetens va escriure:
> > > > The third beta release of RTT 2.0 is availabIe from:
> > > >
> > > > http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > > > http://github.com/psoetens/orocos-rtt
> > > > http://github.com/psoetens/orocos-ocl
> > >
> > > also, fails here, after the Peter's update.
> > >
> > >
> > > In file included
> > > from
> > > /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,
> > >
> > > from
> > > /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
> > > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In
> > > member function ‘void RTT::types::type_discovery::discover(T&)’:
> > > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > > error: wrong number of template arguments (2, should be 1)
> > > /usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
> > > for ‘template<class Archive> struct
> > > boost::archive::detail::load_non_pointer_type’
> > > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > > error: ‘load_only’ has not been declared
> > > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > > error: invalid type in declaration before ‘(’ token
> > > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > > error: invalid use of qualified-name ‘<declaration error>::invoke’
> > > make[2]: ***
> > > [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/SequenceTypeInfo.cp
> > >p.o] Error 1
> > > make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
> >
> > I can confirm this one (with boost 1.42).
>
> Yep, seen this before. The patch in attachment fixes this. I'll push it to
> github.

Not quite, it now fails from type_discovery_test.cpp with the same
error (s.b.). It appears that BOOST_VERSION is not defined in that
path.

Markus

[ 97%] Building CXX object tests/CMakeFiles/type_discovery_test.dir/test-runner.cpp.o
[ 98%] Building CXX object tests/CMakeFiles/type_discovery_test.dir/type_discovery_test.cpp.o
In file included from /home/mk/src/git/gitorocos/rtt-2.0-debian/tests/type_discovery_test.cpp:8:
In file included from /home/mk/src/git/gitorocos/rtt-2.0-debian/tests/type_discovery_test.cpp:9:
/home/mk/src/git/gitorocos/rtt-2.0-debian/rtt/types/type_discovery.hpp: In member function ‘void RTT::types::type_discovery::discover(T&)’:
/home/mk/src/git/gitorocos/rtt-2.0-debian/rtt/types/type_discovery.hpp:113: error: wrong number of template arguments (2, should be 1)
/usr/include/boost/archive/detail/iserializer.hpp:350: error: provided for ‘template<class Archive> struct boost::archive::detail::load_non_pointer_type’
/home/mk/src/git/gitorocos/rtt-2.0-debian/rtt/types/type_discovery.hpp:113: error: ‘load_only’ has not been declared
/home/mk/src/git/gitorocos/rtt-2.0-debian/rtt/types/type_discovery.hpp:113: error: invalid type in declaration before ‘(’ token
/home/mk/src/git/gitorocos/rtt-2.0-debian/rtt/types/type_discovery.hpp:113: error: invalid use of qualified-name ‘<declaration error>::invoke’
make[3]: *** [tests/CMakeFiles/type_discovery_test.dir/type_discovery_test.cpp.o] Error 1
make[3]: Leaving directory `/home/mk/src/git/gitorocos/rtt-2.0-debian/dbuild.gnulinux'
make[2]: *** [tests/CMakeFiles/type_discovery_test.dir/all] Error 2
make[2]: Leaving directory `/home/mk/src/git/gitorocos/rtt-2.0-debian/dbuild.gnulinux'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/mk/src/git/gitorocos/rtt-2.0-debian/dbuild.gnulinux'
make: *** [build-stamp-gnulinux] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

On Tuesday 29 June 2010 13:00:47 Leopold Palomo-Avellaneda wrote:
> A Dilluns 28 Juny 2010, Peter Soetens va escriure:
> > The third beta release of RTT 2.0 is availabIe from:
> >
> > http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > http://github.com/psoetens/orocos-rtt
> > http://github.com/psoetens/orocos-ocl
>
> also, fails here, after the Peter's update.
>
>
> In file included
> from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,
>
> from /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In
> member function ‘void RTT::types::type_discovery::discover(T&)’:
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> error: wrong number of template arguments (2, should be 1)
> /usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
> for ‘template<class Archive> struct
> boost::archive::detail::load_non_pointer_type’
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> error: ‘load_only’ has not been declared
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> error: invalid type in declaration before ‘(’ token
> /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> error: invalid use of qualified-name ‘<declaration error>::invoke’
> make[2]: ***
> [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/SequenceTypeInfo.cpp.
> o] Error 1
> make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2

Boost version ?

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

RTT and OCL 2.0.0-beta3 released

A Dimarts 29 Juny 2010, Peter Soetens va escriure:
> On Tuesday 29 June 2010 13:00:47 Leopold Palomo-Avellaneda wrote:
> > A Dilluns 28 Juny 2010, Peter Soetens va escriure:
> > > The third beta release of RTT 2.0 is availabIe from:
> > >
> > > http://people.mech.kuleuven.be/~orocos/pub/devel/rtt/v1.99.3/
> > > http://github.com/psoetens/orocos-rtt
> > > http://github.com/psoetens/orocos-ocl
> >
> > also, fails here, after the Peter's update.
> >
> >
> > In file included
> > from
> > /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.hpp:5,
> >
> > from
> > /home/leo/robotica/orocos/orocos-git/rtt/types/SequenceTypeInfo.cpp:8:
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp: In
> > member function ‘void RTT::types::type_discovery::discover(T&)’:
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: wrong number of template arguments (2, should be 1)
> > /usr/include/boost/archive/detail/iserializer.hpp:350: error: provided
> > for ‘template<class Archive> struct
> > boost::archive::detail::load_non_pointer_type’
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: ‘load_only’ has not been declared
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: invalid type in declaration before ‘(’ token
> > /home/leo/robotica/orocos/orocos-git/rtt/types/type_discovery.hpp:109:
> > error: invalid use of qualified-name ‘<declaration error>::invoke’
> > make[2]: ***
> > [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/types/SequenceTypeInfo.cp
> >p. o] Error 1
> > make[1]: *** [rtt/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
>
> Boost version ?

1.42 ... it has been a problem of delay in the mail.

--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev