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

> 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?

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

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.