[Rock-dev] [Rock-users] RigidBodyState is changing

Fri Apr 17 07:36:33 CEST 2015

Hi,

 > On 16.04.2015 18:57, Sylvain Joyeux wrote:
 >> backward compatibility. Having a Deprecated class is, as far as I can
 >> see, close to useless as RBS is mainly an orogen interface type, and
 >> one will not be able to connect a Deprecated port to a non-deprecated
 >> port.

Some time ago we started to implement deprecation for port types (not 
the type itself):

https://rock.opendfki.de/ticket/419

And Matthias already had a patch for that (attached to the ticket).

But we actually never tested the results, as the use case vanished.

If we can implement something similar for the types itself, we can solve 
the stable-master issue, as compatibility is not affected.

The port deprecation code works like this:

When you tell the port, its type is deprecated:
output_port("rbs", 
"base/samples/RigidBodyState").deprecates("base/deprecated/samples/RigidBodyState")

Orogen generates two ports:
1. _rbs with type "base/samples/RigidBodyState"
2. _rbs_deprecated with the old type

The magic happens in orocos.rb: When a connection fails, it 
automatically tries to connect the <name>_deprecated port(s) (and pops 
up a deprecation warning). This way, the component can be used with both 
types.

But it still has to implement the handling of both types in cpp (read 
both ports), as long the deprecation period is active.

This is NOT fixing "the name issue", as a rename of the old type is 
needed here. "base/samples/RigidBodyState" -> 
"base/deprecated/samples/RigidBodyState"

Components which don't have the deprecated ports would directly change 
the type, but I wonder if the ports can be auto-deprecated, when they 
use a type that is marked deprecated for orogen in a similar way:

For Example: When base/orogen/types are build, the 
"base/samples/RigidBodyState" type is marked affected by deprecation 
similar to this:

import_deprecated_types_from 'new_type_name' 'header of deprecated type'
or
import_types_from 'base/samples/RigidBodyState' 
"base/samplesdeprecated/RigidBodyState.hpp"

(TODO: think of a good way to use a deprecation command in the orogen 
file, i don't really like this example, it expects one type per header)

This makes orogen generate two types:

'base/samples/RigidBodyState'
'deprecated/base/samples/RigidBodyState'

This way, orogen knows about the deprecated type and could 
automatically deprecate all ports using it.

Still, the internal port name changes (inside Task.cpp) and the code has 
to be touched. But the intitial work to make the code work again is 
minimal (change the read command from "port.read()" to 
"port_deprecated.read()"). The component "works" again, but has no 
support for the new type (the port is not read until it is implemented).

The nice thing about this: All the devs get notified about the change 
and the compiler error will (hopefully) tell a type mismatch between the 
new and the deprecated type, when _port.read() is used with the "wrong" 
type.

This approach is far from being finished, but it could be a start...

At least it allows mixing the branches because a task from master has 
the _deprecated ports and orocos.rb can automatically connect 
*_deprecated output ports to the normal ports of a component from stable 
and vice versa

Steffen

Am 16.04.2015 um 20:08 schrieb Javier Hidalgo Carrió:
> The list of actions are more into "let's have the right RBS
> implementation" than "let's have a smooth transition to the new RBS". I
> am worried more about the first one than about the second one. I
> understand the second issue is an enormous issue which I don't have
> experience with.
>
> Replacing RBS by a new version will break building all-of-Rock as for
> example already happened in the past when changing vizkit3d.
>
> One possible solution I could see is to create new types, e.g.:
> BodyState and BodyAcceleration. To have them together with RBS and
> RBAcceleration and progressively change to the new types. For example,
> making a warning compilation when using the RBS. Maintainers of each
> package would have time to adapt to the new type (similar to when we
> moved from actuators to Joints).
>
> Thanks for the comments and prompt reply,
>
> Javier.
>
> On 16.04.2015 18:57, Sylvain Joyeux wrote:
>> Javier: the plan looks great, and I am very grateful that you try so
>> hard to fix the base types ... But there is IMO still the same
>> unresolved issues, and that's a lot for an "imminent change".
>>
>> You put all over the place "changing the type is not that hard". Have
>> you already changed to the new type ? How much changes did you need to
>> make in your code ? Have you tried building the vanilla (i.e.
>> unmodified) all-of-Rock with the new type in ?
>>
>>   From my perspective, changing a base type *is* hard. It has an effect
>> on day-to-day work for all people that have been using RBS. It breaks
>> backward compatibility. Having a Deprecated class is, as far as I can
>> see, close to useless as RBS is mainly an orogen interface type, and
>> one will not be able to connect a Deprecated port to a non-deprecated
>> port.
>>
>> Mixing the two types will be impossible (since they have the same name
>> but different ABIs). So, that's all-or-nothing: either you change all
>> your code to use the new RBS, or you keep the old one. Mixing stable
>> and master will be unreliable at best. Lot of people will probably end
>> up using master (with the pain and suffering that entails).
>>
>> Does someone have any experience for a wide-ranging change like this ?
>> How would we get to the point where we *do* have experience before we
>> push it to everyone ? How do we avoid just randomly pushing this
>> change to everyone, while many people won't have the time and energy
>> to migrate to a brand new RBS ?
>>
>> There is zero documentation and zero experience for a wide-ranging
>> change like this, and I currently have the impression that the issue
>> of such a change are just brushed off with a "let's do it, it's going
>> to be fine". rock-convert exists, but is documented nowhere.
>>
>> Now, if this "changing RBS is just fine"  is the consensus, I would
>> vote for just creating a new type. At least, we would not pretend that
>> we're providing a clean upgrade path, and won't upset those of us that
>> don't have the time to just migrate to a completely new type that just
>> happens to have kind-of the same API.
>>
>> Finally, you guys seem to push so much towards changing the base
>> types. If that's so high in your agenda, it might be time to put the
>> effort to make the process butter-smooth by doing the necessary
>> toolchain work ?
>>
>> Sylvain
>>
>> On Thu, Apr 16, 2015 at 10:54 AM, Javier Hidalgo Carrió
>> <javier.hidalgo_carrio at dfki.de> wrote:
>>> Hi,
>>>
>>> RigidBodyState (RBS) is changing. There is a list of imminent actions (1
>>> - 10 bullets).
>>> Your comments and alternative solutions are very welcome. Write them here:
>>> https://github.com/rock-core/base-types/wiki/TranformWithUncertainty-in-base-types#list-of-imminent-actions
>>>
>>> Javier.
>>>
>>> _______________________________________________
>>> Rock-users mailing list
>>> Rock-users at dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>

-- 
  Steffen Planthaber
  Weltraumrobotik

  Besuchsadresse der Nebengeschäftstelle:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Postadresse der Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4125
  Zentrale: +49 421 178 45-0
  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   Steffen.Planthaber at dfki.de

  Weitere Informationen: http://www.dfki.de/robotik
  -----------------------------------------------------------------------
  Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
  Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
  Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
  (Vorsitzender) Dr. Walter Olthoff
  Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
  Amtsgericht Kaiserslautern, HRB 2313
  Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
  USt-Id.Nr.:    DE 148646973
  Steuernummer:  19/673/0060/3
  -----------------------------------------------------------------------