-
Notifications
You must be signed in to change notification settings - Fork 33
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
Port capabilities to standalone, ROS and FPrime backends #204
Labels
CR:Status:Closed
Admin only: Change request that has been completed
CR:Type:Feature
Admin only: Change request pertaining to new features requested
Milestone
Comments
Change Manager: Confirmed that the issue exists. |
Technical Lead: Confirmed that the issue should be addressed. |
Technical Lead: Issue scheduled for fixing in Ogma 1.6.0. Fix assigned to: @ivanperez-keera . |
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.,
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
… 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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
… 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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.,
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
… 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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
… 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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…#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.,
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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.
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
…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
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
ivanperez-keera
added a commit
to ivanperez-keera/ogma
that referenced
this issue
Jan 20, 2025
Implementor: Solution implemented, review requested. |
Change Manager: Verified that:
|
Change Manager: Implementation ready to be merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
CR:Status:Closed
Admin only: Change request that has been completed
CR:Type:Feature
Admin only: Change request pertaining to new features requested
Description
The standalone backend is capable of working with different kinds of property languages, as well as with
--parse-prop-via
, but the same features are not available in other backends. It also supports other kinds of JSON/XML formats, instead of using only a fixed format. The diagrams backend also supports the literal property "language", but that's not available in any of the other backends.To improve Ogma altogether and facilitate using the tool, we'd like these features to be present in as many backends as possible.
Type
Additional context
None.
Requester
Method to check presence of bug
Not applicable (not a bug).
Expected result
The standalone backend is capable of supporting the "literal" property language. The ROS and FPrime backends support different file formats, property languages, and the use of external pre-processors like LLMs.
Desired result
The standalone backend is capable of supporting the "literal" property language. The ROS and FPrime backends support different file formats, property languages, and the use of external pre-processors like LLMs.
Proposed solution
Modify standalone backend to support literal format.
Modify ROS backend to support different property formats, file formats and external processors like LLMs.
Modify FPrime backend to support different property formats, file formats and external processors like LLMs.
Further notes
We decide not to include the same ideas wrt. the cFS backend because it's slightly different, and it might be too hard to do as part of the same issue.
The text was updated successfully, but these errors were encountered: