Skip to content
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

ogma-cli: Provide ability to preprocess properties via external command. Refs #197. #198

Merged
merged 8 commits into from
Jan 15, 2025

Conversation

ivanperez-keera
Copy link
Member

Extend Ogma with the ability to preprocess properties by using a user-provided tool, as prescribed in the solution proposed for #197.

…o parse properties. Refs nasa#197.

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.

Because calling an external command will be an IO action, any auxiliary
sub-parsers used by Ogma should be IO actions, rather than pure
functions.

This commit modifies the parser for JSON specifications so that it takes
as argument an IO action to parse individual properties.
… properties. Refs nasa#197.

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 JSON parser to use an external IO action
to parse individual properties, rather than pure functions, which is
suitable when those actions represent calls to external processes.

This commit modifies the ROS and F' backends to wrap parser functions
into IO actions, as required by the modified JSON specification parser.
… properties. Refs nasa#197.

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 JSON parser to use an external IO action
to parse individual properties, rather than pure functions, which is
suitable when those actions represent calls to external processes.

This commit modifies the standalone backend to take an auxiliary command
that is used as the process name to call to parse individual properties.
…ommand. Refs nasa#197.

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 standalone backend with the capability
of taking an auxiliary command as argument and running it to transform
individual properties.

This commit modifies the tests for the standalone command to explicitly
provide no extenal processor, indicating that the properties in the
files tested are in a known format.
…nd. Refs nasa#197.

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 standalone 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
Copy link
Member Author

Change Manager: Verified that:

  • Solution is implemented:
    • The code proposed compiles and passes all tests. Details:
    • The solution proposed produces the expected result. Details:
      The following Dockerfile uses the new flag to produce a Copilot monitor from a spec while replacing all expressions are replaced by the constantly true value / stream, and compiles the resulting Copilot specification, after which it prints the message "Success".
      FROM ubuntu:trusty
      
      RUN apt-get update
      
      RUN apt-get install --yes software-properties-common
      RUN add-apt-repository ppa:hvr/ghc
      RUN apt-get update
      
      RUN apt-get install --yes ghc-8.6.5 cabal-install-2.4
      RUN apt-get install --yes libz-dev
      
      ENV PATH=/opt/ghc/8.6.5/bin:/opt/cabal/2.4/bin:$PWD/.cabal-sandbox/bin:$PATH
      
      RUN cabal update
      RUN cabal v1-sandbox init
      RUN cabal v1-install alex happy --constraint='happy < 2.0'
      RUN apt-get install --yes git
      
      RUN echo "#!/bin/bash" >> /tmp/alwaystrue
      RUN echo "echo TRUE" >> /tmp/alwaystrue
      RUN chmod a+x /tmp/alwaystrue
      
      CMD git clone $REPO && \
          cd $NAME && \
          git checkout $COMMIT && \
          cd .. && \
          cabal v1-install copilot-4.2 $NAME/$PAT**/ --enable-tests && \
          ogma standalone --input-format fdb --file-name $NAME/ogma-cli/examples/DB.json --target-dir output --parse-prop-via /tmp/alwaystrue && \
          cabal v1-exec -- runhaskell output/Copilot.hs && \
          echo "Success"
      Command (substitute variables based on new path after merge):
      $ docker run -e "REPO=https://github.com/ivanperez-keera/ogma" -e "NAME=ogma" -e "PAT=ogma"  -e "COMMIT=e148198cee74b19ee10e850503ec03403efe4372" -it ogma-verify-197
      
  • Implementation is documented. Details:
    All new top-level definitions are documented. The README does not contain a section for the standalone backend, so the feature remains undocumented in the README.
  • Change history is clear.
  • Commit messages are clear.
  • Changelogs are updated.
  • Examples are updated. Details:
    No updates needed.
  • Required version bumps are evaluated. Details:
    Bump not required (API is backwards compatible and dependencies are extended).

@ivanperez-keera ivanperez-keera merged commit 365a723 into nasa:develop Jan 15, 2025
2 checks passed
@ivanperez-keera ivanperez-keera deleted the develop-prefilters branch January 15, 2025 04:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant