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ó >> <[email protected]> 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 >>> [email protected] >>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users > > _______________________________________________ > Rock-dev mailing list > [email protected] > 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: [email protected] 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 ----------------------------------------------------------------------- _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
