Upcoming 1.12.1 release with improved component import/search path semantics.

I'm preparing a 1.12.1 release for RTT/OCL. The biggest improvement is
regarding the import/loadLibrary behavior of OCL and the plugin loaders. We
had already made some advancements on the 2.x branch, but the 1.12 release was
still using an older scheme.

I'm going to write a wiki page to document the 'Orocos package' scheme and how
it is supposed to work for 1.x and 2.x components.
This wraps it up for the 1.12.1 release:

Import + Absolute path:
import("/opt/orocos/lib/orocos")
-> loads components directly under /opt/orocos/lib/orocos and adds it to
import search path (RTT_COMPONENT_PATH).

Import + Relative path:
import("foo/bar")
-> loads components in the subdir 'foo/bar' for each path in the
RTT_COMPONENT_PATH + the current directory

LoadLibrary + Absolute file name:
loadLibrary("/opt/orocos/lib/orocos/libfoo.so")
-> tries to load this file as plugin, as component or if that fails, as a
regular library (was not possible in 1.12.0).

LoadLibrary + Relative file name without 'lib' or '.so' pre/suffixes:
loadLibrary("foo/bar")
-> loads the plugin, typekit or library 'bar' in the 'foo' package under the
RTT_COMPONENT_PATH or the current directory (ie
/opt/orocos/lib/orocos/foo/plugins/libbar.so or
/opt/orocos/lib/orocos/foo/libbar.so or ./foo/libbar.so )

So 'import' takes a directory path and 'loadLibrary' a filename. In order to
test this behavior, it is recommended to run the deployer with the -ldebug
option to see where it searches for the package/library.
One important side effect is that 1.12.0 accepted multiple paths in the
'import' statement, separated by a ';' (this was undocumented). This is no
longer possible in 1.12.1, nor in the 2.x branches.

In addition, we will install components and plugins in the orocos/<target>
directory. The loaders will, when given relative paths, search the given dir
under the RTT_COMPONENT_PATH dirs and their <target> subdirectory so the
migration path shouldn't be an issue here. You can quickly evaluate this by
testing these functions with the -ldebug option in the deployer, and yell here
if you see something weird.

RTT 2.2.x will take a similar scheme, but has the 'path' operation to
explicitly add something to the component search path. Also, 2.x can work with
ROS package trees, which 1.x can't. The aim is to converge importing of
components in 1.14 and 2.3.

Peter

Upcoming 1.12.1 release with improved component import/search pa

On 22/12/2010, at 09:52 , Michaël Presseau wrote:

> We suffer a lot to move from 1.8 to 1.12. We updated because of the Windows support. I also cannot imagine switching to 2.2 version. Some orocos feature changes and does not seem compatible.
>
> Michaël

I briefly tried the 1.10 to 1.12 upgrade, and gave up because of the changes in deployer loading behavior, RTT_COMPONENT_PATH, etc. Good features and things I want to use in the long run, I just don't want to so significantly alter our production and development systems. It's also a whole new learning curve for my existing users.

v2 has a lot of good improvements in it, but it has some radical changes also. It is also, unfortunately, missing some (IMHO) critical features from v1 that prevent any of my customers using v2 at all. Guess we'll cross that bridge at some point ...
S

Upcoming 1.12.1 release with improved component import/search pa

On 12/21/2010 10:02 PM, Stephen Roderick wrote:
> On 22/12/2010, at 09:52 , Michaël Presseau wrote:
>
>> We suffer a lot to move from 1.8 to 1.12. We updated because of the
>> Windows support. I also cannot imagine switching to 2.2 version. Some
>> orocos feature changes and does not seem compatible.
>>
>> Michaël
>
> I briefly tried the 1.10 to 1.12 upgrade, and gave up because of the
> changes in deployer loading behavior, RTT_COMPONENT_PATH, etc. Good
> features and things I want to use in the long run, I just don't want to
> so significantly alter our production and development systems. It's also
> a whole new learning curve for my existing users.
>
> v2 has a lot of good improvements in it, but it has some radical changes
> also. It is also, unfortunately, missing some (IMHO) critical features
> from v1 that prevent any of my customers using v2 at all. Guess we'll
> cross that bridge at some point ...
> S

There doesn't seem to be much point in beating a dead horse, but for
what it is worth, I'd also like to state that we are using RTT 1.10 and
intend to stick with it for now.

Do you think it would be worthwhile to have a page somewhere that says,
"Certain users prefer to not make the switch to 2.x yet. They have this
preference because: <list of reasons>

Incidentally, is there a nice way to access the Orocos component
builder's manual (This is the main orocos RTT document I point students
to, for learning orocos) for older (well, 1.10.x) version of Orocos on
the website? I couldn't find clear links. I had to navigate to it by

www.orocos.org --> Orocos Toolchain --> Older versions --> RTT 1.x -->
damn, I can only find the 'Building components' for v 1.12.x so click on
it anyway --> now let's see what happens if I replace the 12 in the URL
by 10 .. ah, there it is, now save the link for future references.

Not very pretty :)

Regards,
Sagar

Upcoming 1.12.1 release with improved component import/search pa

On Tuesday 21 December 2010 22:15:57 Sagar Behere wrote:
> On 12/21/2010 10:02 PM, Stephen Roderick wrote:
> > On 22/12/2010, at 09:52 , Michaël Presseau wrote:
> >> We suffer a lot to move from 1.8 to 1.12. We updated because of the
> >> Windows support. I also cannot imagine switching to 2.2 version. Some
> >> orocos feature changes and does not seem compatible.
> >>
> >> Michaël
> >
> > I briefly tried the 1.10 to 1.12 upgrade, and gave up because of the
> > changes in deployer loading behavior, RTT_COMPONENT_PATH, etc. Good
> > features and things I want to use in the long run, I just don't want to
> > so significantly alter our production and development systems. It's also
> > a whole new learning curve for my existing users.
> >
> > v2 has a lot of good improvements in it, but it has some radical changes
> > also. It is also, unfortunately, missing some (IMHO) critical features
> > from v1 that prevent any of my customers using v2 at all. Guess we'll
> > cross that bridge at some point ...
> > S
>
> There doesn't seem to be much point in beating a dead horse, but for
> what it is worth, I'd also like to state that we are using RTT 1.10 and
> intend to stick with it for now.
>
> Do you think it would be worthwhile to have a page somewhere that says,
> "Certain users prefer to not make the switch to 2.x yet. They have this
> preference because: <list of reasons>
>
> Incidentally, is there a nice way to access the Orocos component
> builder's manual (This is the main orocos RTT document I point students
> to, for learning orocos) for older (well, 1.10.x) version of Orocos on
> the website? I couldn't find clear links. I had to navigate to it by
>
> www.orocos.org --> Orocos Toolchain --> Older versions --> RTT 1.x -->
> damn, I can only find the 'Building components' for v 1.12.x so click on
> it anyway --> now let's see what happens if I replace the 12 in the URL
> by 10 .. ah, there it is, now save the link for future references.
>
> Not very pretty :)

When you're on the Older versions page, there is a link to

http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/

and

http://people.mech.kuleuven.be/~orocos/pub/stable

Whic you can navigate. Maybe we should omit the two top entries (RTT/OCL 1.x)
to 'force' you into using the links below it... ?

Peter

Upcoming 1.12.1 release with improved component import/search pa

On 12/22/2010 04:49 PM, Peter Soetens wrote:
> On Tuesday 21 December 2010 22:15:57 Sagar Behere wrote:
>> On 12/21/2010 10:02 PM, Stephen Roderick wrote:
>>> On 22/12/2010, at 09:52 , Michaël Presseau wrote:
>>>> We suffer a lot to move from 1.8 to 1.12. We updated because of the
>>>> Windows support. I also cannot imagine switching to 2.2 version. Some
>>>> orocos feature changes and does not seem compatible.
>>>>
>>>> Michaël
>>>
>>> I briefly tried the 1.10 to 1.12 upgrade, and gave up because of the
>>> changes in deployer loading behavior, RTT_COMPONENT_PATH, etc. Good
>>> features and things I want to use in the long run, I just don't want to
>>> so significantly alter our production and development systems. It's also
>>> a whole new learning curve for my existing users.
>>>
>>> v2 has a lot of good improvements in it, but it has some radical changes
>>> also. It is also, unfortunately, missing some (IMHO) critical features
>>> from v1 that prevent any of my customers using v2 at all. Guess we'll
>>> cross that bridge at some point ...
>>> S
>>
>> There doesn't seem to be much point in beating a dead horse, but for
>> what it is worth, I'd also like to state that we are using RTT 1.10 and
>> intend to stick with it for now.
>>
>> Do you think it would be worthwhile to have a page somewhere that says,
>> "Certain users prefer to not make the switch to 2.x yet. They have this
>> preference because:<list of reasons>
>>
>> Incidentally, is there a nice way to access the Orocos component
>> builder's manual (This is the main orocos RTT document I point students
>> to, for learning orocos) for older (well, 1.10.x) version of Orocos on
>> the website? I couldn't find clear links. I had to navigate to it by
>>
>> www.orocos.org --> Orocos Toolchain --> Older versions --> RTT 1.x -->
>> damn, I can only find the 'Building components' for v 1.12.x so click on
>> it anyway --> now let's see what happens if I replace the 12 in the URL
>> by 10 .. ah, there it is, now save the link for future references.
>>
>> Not very pretty :)
>
> When you're on the Older versions page, there is a link to
>
> http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/
>
> and
>
> http://people.mech.kuleuven.be/~orocos/pub/stable
>
> Whic you can navigate. Maybe we should omit the two top entries (RTT/OCL 1.x)
> to 'force' you into using the links below it... ?

Ah, that is indeed true. Can't believe I missed that despite visiting
the page so many times. I believe seeing the RTT 1.x link short-circuits
the brain and you don't think beyond clicking it ;)

/Sagar

Upcoming 1.12.1 release with improved component import/search pa

On 22/12/2010, at 10:15 , Sagar Behere wrote:

> On 12/21/2010 10:02 PM, Stephen Roderick wrote:
>> On 22/12/2010, at 09:52 , Michaël Presseau wrote:
>>
>>> We suffer a lot to move from 1.8 to 1.12. We updated because of the
>>> Windows support. I also cannot imagine switching to 2.2 version. Some
>>> orocos feature changes and does not seem compatible.
>>>
>>> Michaël
>>
>> I briefly tried the 1.10 to 1.12 upgrade, and gave up because of the
>> changes in deployer loading behavior, RTT_COMPONENT_PATH, etc. Good
>> features and things I want to use in the long run, I just don't want to
>> so significantly alter our production and development systems. It's also
>> a whole new learning curve for my existing users.
>>
>> v2 has a lot of good improvements in it, but it has some radical changes
>> also. It is also, unfortunately, missing some (IMHO) critical features
>> from v1 that prevent any of my customers using v2 at all. Guess we'll
>> cross that bridge at some point ...
>> S
>
> There doesn't seem to be much point in beating a dead horse, but for
> what it is worth, I'd also like to state that we are using RTT 1.10 and
> intend to stick with it for now.

Perhaps the better question is "how many v1 users are upgrading beyond 1.10"? I'd also like to hear from Peter about his plans for future v1.x releases, and what the roadmap is. Is the intent that future v1.x releases are supposed to give us an incremental upgrade path to v2? I'd hate for Peter and others to continue to work on v1.12+, and not have many of the v1 users upgrade.

> Do you think it would be worthwhile to have a page somewhere that says,
> "Certain users prefer to not make the switch to 2.x yet. They have this
> preference because: <list of reasons>

I'd recommend a simple comparison page of the pro's and con's of each. There was talk of this once, not sure what came of it ...

> Incidentally, is there a nice way to access the Orocos component
> builder's manual (This is the main orocos RTT document I point students
> to, for learning orocos) for older (well, 1.10.x) version of Orocos on
> the website? I couldn't find clear links. I had to navigate to it by
>
> www.orocos.org --> Orocos Toolchain --> Older versions --> RTT 1.x -->
> damn, I can only find the 'Building components' for v 1.12.x so click on
> it anyway --> now let's see what happens if I replace the 12 in the URL
> by 10 .. ah, there it is, now save the link for future references.

Yes, I've had to do same ... ugh ... I ended up bookmarking it I think ...
S

Upcoming 1.12.1 release with improved component import/search pa

> So 'import' takes a directory path and 'loadLibrary' a filename. In order
to
> test this behavior, it is recommended to run the deployer with the -ldebug
> option to see where it searches for the package/library.
> One important side effect is that 1.12.0 accepted multiple paths in the
> 'import' statement, separated by a ';' (this was undocumented). This is no
> longer possible in 1.12.1, nor in the 2.x branches.

In rtt 1.12.0, we are currently using the ';' separator in the Environnement
Variable RTT_COMPONENT_PATH... It allows us to load multiple path using
RTT_COMPONENT_PATH. ( and also to switch from debug components to release
component). It also allows us to have deployment files that are independ
from the import components operation.

What do you suggest to use for multiples path loading?

Upcoming 1.12.1 release with improved component import/search pa

On Wednesday 22 December 2010 04:38:21 Simon Pelletier-Thibault wrote:
> > So 'import' takes a directory path and 'loadLibrary' a filename. In order
>
> to
>
> > test this behavior, it is recommended to run the deployer with the
> > -ldebug option to see where it searches for the package/library.
> > One important side effect is that 1.12.0 accepted multiple paths in the
> > 'import' statement, separated by a ';' (this was undocumented). This is
> > no longer possible in 1.12.1, nor in the 2.x branches.
>
> In rtt 1.12.0, we are currently using the ';' separator in the
> Environnement Variable RTT_COMPONENT_PATH... It allows us to load multiple
> path using RTT_COMPONENT_PATH. ( and also to switch from debug components
> to release component). It also allows us to have deployment files that are
> independ from the import components operation.
>
> What do you suggest to use for multiples path loading?

This note was only related to the "Import" xml tag or "import" script command.
The RTT_COMPONENT_PATH is still a multi-path list, nothing changed there.

Peter

Upcoming 1.12.1 release with improved component import/search pa

On 21/12/2010, at 23:41 , Peter Soetens wrote:

> I'm preparing a 1.12.1 release for RTT/OCL. The biggest improvement is
> regarding the import/loadLibrary behavior of OCL and the plugin loaders. We
> had already made some advancements on the 2.x branch, but the 1.12 release was
> still using an older scheme.
>
> I'm going to write a wiki page to document the 'Orocos package' scheme and how
> it is supposed to work for 1.x and 2.x components.
> This wraps it up for the 1.12.1 release:
>
> Import + Absolute path:
> import("/opt/orocos/lib/orocos")
> -> loads components directly under /opt/orocos/lib/orocos and adds it to
> import search path (RTT_COMPONENT_PATH).
>
> Import + Relative path:
> import("foo/bar")
> -> loads components in the subdir 'foo/bar' for each path in the
> RTT_COMPONENT_PATH + the current directory
>
> LoadLibrary + Absolute file name:
> loadLibrary("/opt/orocos/lib/orocos/libfoo.so")
> -> tries to load this file as plugin, as component or if that fails, as a
> regular library (was not possible in 1.12.0).
>
> LoadLibrary + Relative file name without 'lib' or '.so' pre/suffixes:
> loadLibrary("foo/bar")
> -> loads the plugin, typekit or library 'bar' in the 'foo' package under the
> RTT_COMPONENT_PATH or the current directory (ie
> /opt/orocos/lib/orocos/foo/plugins/libbar.so or
> /opt/orocos/lib/orocos/foo/libbar.so or ./foo/libbar.so )
>
> So 'import' takes a directory path and 'loadLibrary' a filename. In order to
> test this behavior, it is recommended to run the deployer with the -ldebug
> option to see where it searches for the package/library.
> One important side effect is that 1.12.0 accepted multiple paths in the
> 'import' statement, separated by a ';' (this was undocumented). This is no
> longer possible in 1.12.1, nor in the 2.x branches.
>
> In addition, we will install components and plugins in the orocos/<target>
> directory. The loaders will, when given relative paths, search the given dir
> under the RTT_COMPONENT_PATH dirs and their <target> subdirectory so the
> migration path shouldn't be an issue here. You can quickly evaluate this by
> testing these functions with the -ldebug option in the deployer, and yell here
> if you see something weird.
>
> RTT 2.2.x will take a similar scheme, but has the 'path' operation to
> explicitly add something to the component search path. Also, 2.x can work with
> ROS package trees, which 1.x can't. The aim is to converge importing of
> components in 1.14 and 2.3.
>
> Peter

I'm curious as to how many users are still using the v1 series? Also, at what point do we plan to stop improving v1?

FYI we are staying with 1.10 and are not sure whether we'll update beyond that, before jumping to the v2 versions next year. There were too many changes like the above in 1.12, for us to consider updating production systems. We may skip the rest of the v1 series and jump straight to v2, once all the v1 features we use actually exist in 2.x.
S

Upcoming 1.12.1 release with improved component import/search pa

Switching from a version to another is a really pain. In our company we are
using Orocos 1.10 in a quite big application and updating to 1.12 is quite a
challenge so I don't think about switching to 2.2...

2010/12/21 S Roderick <kiwi [dot] net [..] ...>

> On 21/12/2010, at 23:41 , Peter Soetens wrote:
>
> > I'm preparing a 1.12.1 release for RTT/OCL. The biggest improvement is
> > regarding the import/loadLibrary behavior of OCL and the plugin loaders.
> We
> > had already made some advancements on the 2.x branch, but the 1.12
> release was
> > still using an older scheme.
> >
> > I'm going to write a wiki page to document the 'Orocos package' scheme
> and how
> > it is supposed to work for 1.x and 2.x components.
> > This wraps it up for the 1.12.1 release:
> >
> > Import + Absolute path:
> > import("/opt/orocos/lib/orocos")
> > -> loads components directly under /opt/orocos/lib/orocos and adds it to
> > import search path (RTT_COMPONENT_PATH).
> >
> > Import + Relative path:
> > import("foo/bar")
> > -> loads components in the subdir 'foo/bar' for each path in the
> > RTT_COMPONENT_PATH + the current directory
> >
> > LoadLibrary + Absolute file name:
> > loadLibrary("/opt/orocos/lib/orocos/libfoo.so")
> > -> tries to load this file as plugin, as component or if that fails, as a
> > regular library (was not possible in 1.12.0).
> >
> > LoadLibrary + Relative file name without 'lib' or '.so' pre/suffixes:
> > loadLibrary("foo/bar")
> > -> loads the plugin, typekit or library 'bar' in the 'foo' package under
> the
> > RTT_COMPONENT_PATH or the current directory (ie
> > /opt/orocos/lib/orocos/foo/plugins/libbar.so or
> > /opt/orocos/lib/orocos/foo/libbar.so or ./foo/libbar.so )
> >
> > So 'import' takes a directory path and 'loadLibrary' a filename. In order
> to
> > test this behavior, it is recommended to run the deployer with the
> -ldebug
> > option to see where it searches for the package/library.
> > One important side effect is that 1.12.0 accepted multiple paths in the
> > 'import' statement, separated by a ';' (this was undocumented). This is
> no
> > longer possible in 1.12.1, nor in the 2.x branches.
> >
> > In addition, we will install components and plugins in the
> orocos/<target>
> > directory. The loaders will, when given relative paths, search the given
> dir
> > under the RTT_COMPONENT_PATH dirs and their <target> subdirectory so the
> > migration path shouldn't be an issue here. You can quickly evaluate this
> by
> > testing these functions with the -ldebug option in the deployer, and yell
> here
> > if you see something weird.
> >
> > RTT 2.2.x will take a similar scheme, but has the 'path' operation to
> > explicitly add something to the component search path. Also, 2.x can work
> with
> > ROS package trees, which 1.x can't. The aim is to converge importing of
> > components in 1.14 and 2.3.
> >
> > Peter
>
> I'm curious as to how many users are still using the v1 series? Also, at
> what point do we plan to stop improving v1?
>
> FYI we are staying with 1.10 and are not sure whether we'll update beyond
> that, before jumping to the v2 versions next year. There were too many
> changes like the above in 1.12, for us to consider updating production
> systems. We may skip the rest of the v1 series and jump straight to v2, once
> all the v1 features we use actually exist in 2.x.
> S
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

Upcoming 1.12.1 release with improved component import/search pa

We suffer a lot to move from 1.8 to 1.12. We updated because of the Windows support. I also cannot imagine switching to 2.2 version. Some orocos feature changes and does not seem compatible.

Michaël

Upcoming 1.12.1 release with improved component import/search pa

On Tuesday 21 December 2010 21:52:13 Michaël Presseau wrote:
> We suffer a lot to move from 1.8 to 1.12. We updated because of the Windows
> support. I also cannot imagine switching to 2.2 version. Some orocos
> feature changes and does not seem compatible.

The Windows support for component loading / deployment was the main reason to
release 1.12.0, next to some bugfixes that could not be merged in 1.10.x.

This support was implemented by backporting the 2.x component loading code
that uses boost::file_system. Since that code had not much time to mature, some
issues were still present in the 1.12.0 release.

The idea was yet simple: dump your components in a directory, point your
RTT_COMPONENT_PATH to that directory and load every library in that directory
when you start the deployer.

This is fairly compatible with the 1.10 approach, but with these exceptions:
- We no longer look for the -gnulinux, -lxrt, -... target suffixes, which means
you can't mix components of different targets in the same directory
- For this same reason, on win32, you need to install 'Debug' and 'Release'
libs in different directories and start with a different RTT_COMPONENT_PATH to
switch
- We dropped loading 'regular' libraries, which was accidental, since that
breaks a lot of 1.x apps out there. This is fixed in 1.12.1.
- We require that you provide *directories* to Import and *filenames* to
LoadLibrary. This was the biggest backwards compatibility problem since people
could only use the Import command in pre-1.12, which mixed libraries and
paths.

Any issues can be debugged with running -ldebug, which will show you where it
searched and what it was looking for.

Even with all the good intentions, 1.12.0 did not do always the logical or the
right thing. It's a public secret that our .0 releases usually require some
tweaking before we get it right. There is no other way to iterate.

Deployment in 1.12.0 surely needs some fixing to minimize the upgrade pains,
but in the end, the user should change (or remove) *at most* only the import
statements in existing deployment files, nothing else. It seemed a fair trade-
off to gain Windows support and RTT_COMPONENT_PATH (ie multi-path) loading.

Peter

Upcoming 1.12.1 release with improved component import/search pa

[Willy, DON'T TOP POST]

On 22/12/2010, at 09:03 , Willy Lambert wrote:

> Switching from a version to another is a really pain. In our company we are using Orocos 1.10 in a quite big application and updating to 1.12 is quite a challenge so I don't think about switching to 2.2...
>
> 2010/12/21 S Roderick <kiwi [dot] net [..] ...>
> On 21/12/2010, at 23:41 , Peter Soetens wrote:
>
> > I'm preparing a 1.12.1 release for RTT/OCL. The biggest improvement is
> > regarding the import/loadLibrary behavior of OCL and the plugin loaders. We
> > had already made some advancements on the 2.x branch, but the 1.12 release was
> > still using an older scheme.
> >
> > I'm going to write a wiki page to document the 'Orocos package' scheme and how
> > it is supposed to work for 1.x and 2.x components.
> > This wraps it up for the 1.12.1 release:
> >
> > Import + Absolute path:
> > import("/opt/orocos/lib/orocos")
> > -> loads components directly under /opt/orocos/lib/orocos and adds it to
> > import search path (RTT_COMPONENT_PATH).
> >
> > Import + Relative path:
> > import("foo/bar")
> > -> loads components in the subdir 'foo/bar' for each path in the
> > RTT_COMPONENT_PATH + the current directory
> >
> > LoadLibrary + Absolute file name:
> > loadLibrary("/opt/orocos/lib/orocos/libfoo.so")
> > -> tries to load this file as plugin, as component or if that fails, as a
> > regular library (was not possible in 1.12.0).
> >
> > LoadLibrary + Relative file name without 'lib' or '.so' pre/suffixes:
> > loadLibrary("foo/bar")
> > -> loads the plugin, typekit or library 'bar' in the 'foo' package under the
> > RTT_COMPONENT_PATH or the current directory (ie
> > /opt/orocos/lib/orocos/foo/plugins/libbar.so or
> > /opt/orocos/lib/orocos/foo/libbar.so or ./foo/libbar.so )
> >
> > So 'import' takes a directory path and 'loadLibrary' a filename. In order to
> > test this behavior, it is recommended to run the deployer with the -ldebug
> > option to see where it searches for the package/library.
> > One important side effect is that 1.12.0 accepted multiple paths in the
> > 'import' statement, separated by a ';' (this was undocumented). This is no
> > longer possible in 1.12.1, nor in the 2.x branches.
> >
> > In addition, we will install components and plugins in the orocos/<target>
> > directory. The loaders will, when given relative paths, search the given dir
> > under the RTT_COMPONENT_PATH dirs and their <target> subdirectory so the
> > migration path shouldn't be an issue here. You can quickly evaluate this by
> > testing these functions with the -ldebug option in the deployer, and yell here
> > if you see something weird.
> >
> > RTT 2.2.x will take a similar scheme, but has the 'path' operation to
> > explicitly add something to the component search path. Also, 2.x can work with
> > ROS package trees, which 1.x can't. The aim is to converge importing of
> > components in 1.14 and 2.3.
> >
> > Peter
>
> I'm curious as to how many users are still using the v1 series? Also, at what point do we plan to stop improving v1?
>
> FYI we are staying with 1.10 and are not sure whether we'll update beyond that, before jumping to the v2 versions next year. There were too many changes like the above in 1.12, for us to consider updating production systems. We may skip the rest of the v1 series and jump straight to v2, once all the v1 features we use actually exist in 2.x.
> S

I agree that it is a pain to change versions like this, but also, we have to upgrade at some point. v1 development must cease at some point so that development can focus solely on v2 ... v3 ...
S

Upcoming 1.12.1 release with improved component import/search pa

2010/12/21 Stephen Roderick <kiwi [dot] net [..] ...>

> [Willy, DON'T TOP POST]
>
> On 22/12/2010, at 09:03 , Willy Lambert wrote:
>
> Switching from a version to another is a really pain. In our company we are
> using Orocos 1.10 in a quite big application and updating to 1.12 is quite a
> challenge so I don't think about switching to 2.2...
>
> 2010/12/21 S Roderick <kiwi [dot] net [..] ...>
>
>> On 21/12/2010, at 23:41 , Peter Soetens wrote:
>>
>> > I'm preparing a 1.12.1 release for RTT/OCL. The biggest improvement is
>> > regarding the import/loadLibrary behavior of OCL and the plugin loaders.
>> We
>> > had already made some advancements on the 2.x branch, but the 1.12
>> release was
>> > still using an older scheme.
>> >
>> > I'm going to write a wiki page to document the 'Orocos package' scheme
>> and how
>> > it is supposed to work for 1.x and 2.x components.
>> > This wraps it up for the 1.12.1 release:
>> >
>> > Import + Absolute path:
>> > import("/opt/orocos/lib/orocos")
>> > -> loads components directly under /opt/orocos/lib/orocos and adds it to
>> > import search path (RTT_COMPONENT_PATH).
>> >
>> > Import + Relative path:
>> > import("foo/bar")
>> > -> loads components in the subdir 'foo/bar' for each path in the
>> > RTT_COMPONENT_PATH + the current directory
>> >
>> > LoadLibrary + Absolute file name:
>> > loadLibrary("/opt/orocos/lib/orocos/libfoo.so")
>> > -> tries to load this file as plugin, as component or if that fails, as
>> a
>> > regular library (was not possible in 1.12.0).
>> >
>> > LoadLibrary + Relative file name without 'lib' or '.so' pre/suffixes:
>> > loadLibrary("foo/bar")
>> > -> loads the plugin, typekit or library 'bar' in the 'foo' package under
>> the
>> > RTT_COMPONENT_PATH or the current directory (ie
>> > /opt/orocos/lib/orocos/foo/plugins/libbar.so or
>> > /opt/orocos/lib/orocos/foo/libbar.so or ./foo/libbar.so )
>> >
>> > So 'import' takes a directory path and 'loadLibrary' a filename. In
>> order to
>> > test this behavior, it is recommended to run the deployer with the
>> -ldebug
>> > option to see where it searches for the package/library.
>> > One important side effect is that 1.12.0 accepted multiple paths in the
>> > 'import' statement, separated by a ';' (this was undocumented). This is
>> no
>> > longer possible in 1.12.1, nor in the 2.x branches.
>> >
>> > In addition, we will install components and plugins in the
>> orocos/<target>
>> > directory. The loaders will, when given relative paths, search the given
>> dir
>> > under the RTT_COMPONENT_PATH dirs and their <target> subdirectory so the
>> > migration path shouldn't be an issue here. You can quickly evaluate this
>> by
>> > testing these functions with the -ldebug option in the deployer, and
>> yell here
>> > if you see something weird.
>> >
>> > RTT 2.2.x will take a similar scheme, but has the 'path' operation to
>> > explicitly add something to the component search path. Also, 2.x can
>> work with
>> > ROS package trees, which 1.x can't. The aim is to converge importing of
>> > components in 1.14 and 2.3.
>> >
>> > Peter
>>
>> I'm curious as to how many users are still using the v1 series? Also, at
>> what point do we plan to stop improving v1?
>>
>> FYI we are staying with 1.10 and are not sure whether we'll update beyond
>> that, before jumping to the v2 versions next year. There were too many
>> changes like the above in 1.12, for us to consider updating production
>> systems. We may skip the rest of the v1 series and jump straight to v2, once
>> all the v1 features we use actually exist in 2.x.
>> S
>>
>
> I agree that it is a pain to change versions like this, but also, we have
> to upgrade at some point. v1 development must cease at some point so that
> development can focus solely on v2 ... v3 ...
> S
>

Of course, but if the question is "is anybody struck with 1.x" and the
answer is yes.