Morning, I think it it really a good way to improving base types. Thank's to all dev's for their contribution (regarding this and for everything else too).
BUT regarding changing a so deep and wide used base time we need a more powerful tooling. Specially a announcement on rock-users is not what we need here specially it is not discussed within the dev group before. I don't know if we should revert this "is chaining" statement on rock-users now because it would feel strange that we revert meanings there... Nevertheless, There was already a few discussions and thoughts regarding dynamic conversion and port deprecation features. As long as we don't have implemented these framework based compatibility function i would not provide a recommendation from a developer point of view to the 'customers'. New types can be used if someone needs them. BUT to really integrate them in the framework we need a way to convert them on the fly (if possible), or provide a transparent way to realize both approaches. I think we should put this on the Agenda for the next meeting. Matthias On 17.04.2015 09:10, Dennis Mronga wrote: > Hi, > > changing RBS like this would indeed affect a lot of code. I would really > consider whether the actual improvements are worth the pain. > > However, if there is consensus to do it, please don't use base::Wrench > for representing accelerations. base::Wrench is representing Cartesian > forces and torques. Acceleration should be another type. > > Furthermore, I like the idea of having Pose, Twist and Acceleration > types, which can be used separately or (together) in RigidBodyState > (which is the idea, if I get it right!?). > > Best, > Dennis > > On 17.04.2015 07:36, Steffen Planthaber wrote: >> 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 >>> -- Dipl.-Inf. Matthias Goldhoorn Space and Underwater Robotic Universität Bremen FB 3 - Mathematik und Informatik AG Robotik Robert-Hooke-Straße 1 28359 Bremen, Germany Zentrale: +49 421 178 45-6611 Besuchsadresse der Nebengeschäftstelle: Robert-Hooke-Straße 5 28359 Bremen, Germany Tel.: +49 421 178 45-4193 Empfang: +49 421 178 45-6600 Fax: +49 421 178 45-4150 E-Mail: [email protected] Weitere Informationen: http://www.informatik.uni-bremen.de/robotik _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
