Community
Participate
Working Groups
For model elements where the RSARTE name differs from the Papyrus-RT name, the model importer will need to change the element to the Papyrus-RT equivalent. For opaque behaviors, an adaptation will be required. When that is the case, it will be indicated in the tables in the "Adaptation Layer" column. Protocols Timing: Rename from "UMLRTTimerProtocol" to "Timing" in both RTS and model library. No adaptation layer needed. Log: Rename from "UMLRTLogProtocol" to "Log" in both RTS and model library. No adaptation layer needed. Frame: Rename from "UMLRTFrameProtocol" to "Frame" in both RTS and model library. No adaptation layer needed. External: Implement using RSARTE name. No adaptation layer needed. Exception: Implement using RSARTE name.. No adaptation layer needed. Types RTActorId: Change type of properties from "RTActorId" to "UMLRTCapsuleId" on import. Create a "RTActorId" adaptor. RTTimerId Change type of properties from "RTTimerId" to "UMLRTTimerId" on import. Create a "RTTimerId" adaptor. RTTimespec: Change type of properties from "RTTimespec" to "UMLRTTimeSpec" on import. Create a "RTTimespec" adaptor. RTMessage: Change type of properties from "RTMessage" to "UMLRTMessage on import. Create a "RTMessage" adaptor. RTBoolean, RTByteBlock, RTCharacter, RTDataObject, RTEnumerated, RTInteger, RTpchar, RTPointer, RTpvoid, RTReal, RTSequence, RTSequenceOf, RTString, RTTime, RTuchar, RTulong, and RTushort: Determine best approach to implement in RTS (e.g., map to existing RTS types, C++ types, or implement new). Add to model library. Create adaptor if required.
I see that this Bugzilla have been assigned to Papyrus-RT and the tooling component. But if this about the updating the RSA import tool then I guess it really should be assigned to Papyrus since the import tool is still part of the Papyrus Extras. Or is this Bugzilla related to the activities that the Papyrus-RT project will perform, and yet another Bugzilla will be written specifically for the import tool in Papyrus?
(In reply to Peter Cigéhn from comment #1) > I see that this Bugzilla have been assigned to Papyrus-RT and the tooling > component. But if this about the updating the RSA import tool then I guess > it really should be assigned to Papyrus since the import tool is still part > of the Papyrus Extras. Or is this Bugzilla related to the activities that > the Papyrus-RT project will perform, and yet another Bugzilla will be > written specifically for the import tool in Papyrus? Bug 477714 was created to address the model import tooling side and marked as depending on this one.
Perhaps primitive C++ types (from the CppPrimitiveDataTypes model library) should be mapped to the AnsiC model library (included in the Papyrus C++ profile). This is the one that we use currently.
(In reply to Ernesto Posse from comment #3) > Perhaps primitive C++ types (from the CppPrimitiveDataTypes model library) > should be mapped to the AnsiC model library (included in the Papyrus C++ > profile). This is the one that we use currently. That was my first thought as well. We need to check the latter for completeness against the former.
I checked the Papyrus AnsiCLibrary and compared it with the RSARTE CppPrimitiveDatatypes library and found a few types that exist in CppPrimitiveDatatypes, but not in AnsiCLibrary: byte unsigned The existence of 'byte' seem to be a bit strange, since C/C++ does not have any such type. I tried to generate code to see if the code generator in RSARTE did some "magic" with it, but it simply generates a 'byte' (which then does not compile). I've checked some legacy models and I cannot find any use of 'byte'. So I guess this should not be an issue if AnsiCLibrary is chosen (but it could of course exist other legacy models which uses 'byte' and have made their own mapping using #define or similar solutions). When it comes to unsigned though I am a bit uncertain how we want to treat it. Yes an 'unsigned' is implicitly an 'unsigned int'. But I am not sure of the consequence if we during import should map all 'unsigned' to 'unsigned int'. There are some use of 'unsigned' in the legacy models that I checked (but the use of 'unsigned int' is used about 10 times more). We could probably have the same discussion and argumentation that we have had off-line regarding if the run-time model library should be a shared, generic, target language agnostic one, or if we should have a specific run-time model library per target language. Should we reuse the Papyrus AnsiCLibrary, or should we "decouple" and make a specific C++ library more "coupled" to the C++ run-time and code-generator, a library which can be changed without impacting the user-base of the AnsiCLibrary? Not that I foresee that this will ever happen once the library is in place, but anyway... :)
(In reply to Peter Cigéhn from comment #5) > I checked the Papyrus AnsiCLibrary and compared it with the RSARTE > CppPrimitiveDatatypes library and found a few types that exist in > CppPrimitiveDatatypes, but not in AnsiCLibrary: > > byte > unsigned > > The existence of 'byte' seem to be a bit strange, since C/C++ does not have > any such type. I tried to generate code to see if the code generator in > RSARTE did some "magic" with it, but it simply generates a 'byte' (which > then does not compile). I've checked some legacy models and I cannot find > any use of 'byte'. So I guess this should not be an issue if AnsiCLibrary is > chosen (but it could of course exist other legacy models which uses 'byte' > and have made their own mapping using #define or similar solutions). > > When it comes to unsigned though I am a bit uncertain how we want to treat > it. Yes an 'unsigned' is implicitly an 'unsigned int'. But I am not sure of > the consequence if we during import should map all 'unsigned' to 'unsigned > int'. There are some use of 'unsigned' in the legacy models that I checked > (but the use of 'unsigned int' is used about 10 times more). "Unsigned" has been an issue for a while as it is both a keyword and a type. From a C/C++ legacy, unsigned has been equivalent to "unsigned int" (when not followed by a type) in all compilers I've used for as long as I remember. In the same way, "byte" has traditionally been defined as an "unsigned char" - many older C compiler had "byte" defined as part of their standard headers. Current practice seems to be more aligned to using "uint_8" to define a "byte". > > We could probably have the same discussion and argumentation that we have > had off-line regarding if the run-time model library should be a shared, > generic, target language agnostic one, or if we should have a specific > run-time model library per target language. Should we reuse the Papyrus > AnsiCLibrary, or should we "decouple" and make a specific C++ library more > "coupled" to the C++ run-time and code-generator, a library which can be > changed without impacting the user-base of the AnsiCLibrary? Not that I > foresee that this will ever happen once the library is in place, but > anyway... :) I think we need to figure out how do deal with RSARTE's "RT..." types before getting into that decision.
As Peter indicated, there is a close match between RSARTE's CppPrimitiveDataTypes and Papyrus' AnsiCLibrary. Here is my Suggestion for the mapping: bool map to AnsiCLibrary's bool byte map to AnsiCLibrary's uint8 char map to AnsiCLibrary's char double map to AnsiCLibrary's double float map to AnsiCLibrary's float int map to AnsiCLibrary's int long map to AnsiCLibrary's long short map to AnsiCLibrary's short unsigned map to AnsiCLibrary's unsigned int unsigned char map to AnsiCLibrary's unsigned char unsigned int map to AnsiCLibrary's unsigned int unsigned long map to AnsiCLibrary's unsigned long unsigned short map to AnsiCLibrary's unsigned short void map to AnsiCLibrary's void wchar_t map to AnsiCLibrary's wchar_t
(In reply to Charles Rivet from comment #6) > I think we need to figure out how do deal with RSARTE's "RT..." types before > getting into that decision. I wrote a separate Bugzilla related to that decision, see Bug 478797, and made it block this Bugzilla.
Can we have the model importer modified to do the following mappings: RTActorId: Change type of properties from "RTActorId" to "UMLRTCapsuleId" on import. Create a "RTActorId" adaptor. RTTimerId Change type of properties from "RTTimerId" to "UMLRTTimerId" on import. Create a "RTTimerId" adaptor. RTTimespec: Change type of properties from "RTTimespec" to "UMLRTTimeSpec" on import. Create a "RTTimespec" adaptor. RTMessage: Change type of properties from "RTMessage" to "UMLRTMessage on import. Create a "RTMessage" adaptor. For the following, map to the obvious Ansi C model library types. If there is not obvious mapping, such as with RTString, then leave it out and we will add that to the UMLRT model library. RTBoolean, RTByteBlock, RTCharacter, RTDataObject, RTEnumerated, RTInteger, RTpchar, RTPointer, RTpvoid, RTReal, RTSequence, RTSequenceOf, RTString, RTTime, RTuchar, RTulong, and RTushort
Ignore the previous comment.
I guess that this one should not be part of the 0.8.0 release. Charles, can we reset the target milestone on this one?
Moved to 0.9 as this is mainly related to behavior.
(In reply to Charles Rivet from comment #12) > Moved to 0.9 as this is mainly related to behavior. This one is still for 'Future', where previous comment says '0.9'? It also blocks 477714, planned for 0.9.0 Should we move it also to 0.9.0?
(In reply to Remi Schnekenburger from comment #13) > (In reply to Charles Rivet from comment #12) > > Moved to 0.9 as this is mainly related to behavior. > > This one is still for 'Future', where previous comment says '0.9'? It also > blocks 477714, planned for 0.9.0 > Should we move it also to 0.9.0? No, this one should probably still be future. The blocked Bug 477714 is the one that should be moved to future (or at least swap the order so that this one comes before the blocked, since this is the investigation bug and the other tracks the implementation). Please also see my comment related to this, Bug 477714 Comment 4.
