-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend support for file, property formats across backends #205
Merged
ivanperez-keera
merged 27 commits into
nasa:develop
from
ivanperez-keera:develop-versatile
Jan 20, 2025
Merged
Extend support for file, property formats across backends #205
ivanperez-keera
merged 27 commits into
nasa:develop
from
ivanperez-keera:develop-versatile
Jan 20, 2025
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ogma used to support only one kind of input file that used the term Component Spec for its specification. That is no longer the case, since now other kinds of formats, in JSON, XML and diagrams are supported. This commit changes a comment accordingly.
ivanperez-keera
force-pushed
the
develop-versatile
branch
from
January 20, 2025 21:22
02fc857
to
19e97f5
Compare
Ogma-test were originally centered around a specific file format but, with the support for new formats in JSON, XML and diagrams, it's become more versatile. This commit renames examples to organize them based on the file formats they use, as defined by the file format property in the CLI.
Ogma-test were originally centered around a specific file format but, with the support for new formats in JSON, XML and diagrams, it's become more versatile. This commit renames tests and test files to organize them based on backends and the file formats they use, as defined by the file format property values supported by ogma-core.
ivanperez-keera
force-pushed
the
develop-versatile
branch
from
January 20, 2025 21:34
19e97f5
to
f1a2757
Compare
Ogma-test were originally centered around a specific file format but, with the support for new formats in JSON, XML and diagrams, it's become more versatile. This commit renames tests and test files to organize them based on the file formats they use, as defined by the file format property in the CLI.
…asa#204. The diagram backend supports literal Copilot expressions, but that capability is not yet available in the standalone backend. This commit adds the capability by introducing a new expression pair or property parsing/printing handler.
The ROS backend used to be specialized for one file format as input, which was reflected in the name of the options expected by the backend. For consistency across backend, and to facilitate the introduction of support for different kinds of file formats in the future, we rename the backend's options to be more format-agnostic.
The ROS backend used to be specialized for one file format as input, which was reflected in the name of the options expected by the backend. A prior commit has renamed the options expected by Ogma's backend in ogma-core to make them more format-agnostic, in alignment with the plan to support different kinds of file formats. This commit performs the same change for users in the CLI.,
The ROS backend has a large amount of input options, making it cumbersome to pass them around. This commit packs those options in a record, making the signature of the top-level function simpler and more uniform.
The ROS backend has a large amount of input options, making it cumbersome to pass them around. A prior commit has modified the backend in ogma-core to packs those options in a record, making the signature of the top-level function simpler and more uniform. This commit adapts the CLI to provide the arguments in a record as required by the updated backend.
… Refs nasa#204. The standalone backend supports cocospec, smv and literal Copilot expressions, but that capability is not yet available in the ROS backend. This commit adds that capability by introducing a notion of expression pairs or expression input file handlers parser can use to parse expressions or properties contained in input files.
…Refs nasa#204. The standalone backend supports cocospec, smv and literal Copilot expressions, but that capability is not yet available in the ROS backend. A prior commit has added to ogma-core the the capability of handling expressions in multiple languages.
…sa#204. The standalone backend supports JSON and XML, which can be further confirured in the command line, but that capability is not yet available in the ROS backend. This commit adds that capability by introducing the capability of handling JSON and XML file formats, and reading the specific paths of the elements needed in properties from the command line.
…a#204. The standalone backend supports JSON and XML, which can be further confirured in the command line, but that capability is not yet available in the ROS backend in the command line interface. A prior commit has expanded the ROS backend in ogma-core with support for the aforementioned capability. This commit exposes the new capability to the user in the CLI.
…ties. Refs nasa#204. There is a need in Ogma to make the frontend more versatile, and to extend it to support languages unknown to Ogma without users having to modify the code of Ogma itself. To that end, we want to empower users with the ability to use a custom command to transform individual properties into a format that Ogma understands, and have Ogma call that external command on demand. This capability is already available in the standalone backend, but not in other backends. This commit modifies the ROS backend to take an auxiliary command that is used as the process name to call to parse individual properties.
… properties. Refs nasa#204. There is a need in Ogma to make the frontend more versatile, and to extend it to support languages unknown to Ogma without users having to modify the code of Ogma itself. To that end, we want to empower users with the ability to use a custom command to transform individual properties into a format that Ogma understands, and have Ogma call that external command on demand. Prior commits have extended the ROS backend with the capability of taking an auxiliary command as argument and running it to transform individual properties. This commit exposes that new argument to the user in the CLI.
…a#204. The FPrime backend used to be specialized for one file format as input, which was reflected in the name of the options expected by the backend. For consistency across backend, and to facilitate the introduction of support for different kinds of file formats in the future, we rename the backend's options to be more format-agnostic.
…#204. The FPrime backend used to be specialized for one file format as input, which was reflected in the name of the options expected by the backend. A prior commit has renamed the options expected by Ogma's backend in ogma-core to make them more format-agnostic, in alignment with the plan to support different kinds of file formats. This commit performs the same change for users in the CLI.,
The FPrime backend has a large amount of input options, making it cumbersome to pass them around. This commit packs those options in a record, making the signature of the top-level function simpler and more uniform.
The FPrime backend has a large amount of input options, making it cumbersome to pass them around. A prior commit has modified the backend in ogma-core to packs those options in a record, making the signature of the top-level function simpler and more uniform. This commit adapts the CLI to provide the arguments in a record as required by the updated backend.
…ts. Refs nasa#204. The standalone backend supports cocospec, smv and literal Copilot expressions, but that capability is not yet available in the FPrime backend. This commit adds that capability by introducing a notion of expression pairs or expression input file handlers parser can use to parse expressions or properties contained in input files.
…s. Refs nasa#204. The standalone backend supports cocospec, smv and literal Copilot expressions, but that capability is not yet available in the FPrime backend. A prior commit has added to ogma-core the the capability of handling expressions in multiple languages.
…asa#204. The standalone backend supports JSON and XML, which can be further confirured in the command line, but that capability is not yet available in the FPrime backend. This commit adds that capability by introducing the capability of handling JSON and XML file formats, and reading the specific paths of the elements needed in properties from the command line.
…asa#204. The standalone backend supports JSON and XML, which can be further confirured in the command line, but that capability is not yet available in the FPrime backend in the command line interface. A prior commit has expanded the FPrime backend in ogma-core with support for the aforementioned capability. This commit exposes the new capability to the user in the CLI.
…perties. Refs nasa#204. There is a need in Ogma to make the frontend more versatile, and to extend it to support languages unknown to Ogma without users having to modify the code of Ogma itself. To that end, we want to empower users with the ability to use a custom command to transform individual properties into a format that Ogma understands, and have Ogma call that external command on demand. This capability is already available in the standalone backend, but not in other backends. This commit modifies the FPrime backend to take an auxiliary command that is used as the process name to call to parse individual properties.
…rse properties. Refs nasa#204. There is a need in Ogma to make the frontend more versatile, and to extend it to support languages unknown to Ogma without users having to modify the code of Ogma itself. To that end, we want to empower users with the ability to use a custom command to transform individual properties into a format that Ogma understands, and have Ogma call that external command on demand. Prior commits have extended the FPrime backend with the capability of taking an auxiliary command as argument and running it to transform individual properties. This commit exposes that new argument to the user in the CLI.
ivanperez-keera
force-pushed
the
develop-versatile
branch
from
January 20, 2025 21:56
f1a2757
to
0a21238
Compare
Change Manager: Verified that:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Extend support for file, property formats across backends, including the "literal" property format for the standalone backend and all the same supported property formats, file formats, and use of external processors for ROS and FPrime, as prescribed in the solution proposed for #204.