*`-i <index>` - Use this option to test just the .mp model at this index.
*`-s <scope>` - Use this to specify the scope, default scope is one.
The test generates the following output:
The test generates the following output under the same directory in files and directories prefixed with `_test`:
* CSV log
* Trace and global view graphs
* Runtime status
#### CSV log
The CSV log is a comma separated value output file that can be imported into a spreadsheet. It contains totals of various attributes, useful for quantifying generated attributes and for detecting changes due to modifications or regression. Columns include:
* Filename
* Schema name
* File hashcode
* Scope
* Run time, in seconds
* Number of traces generated
* For traces, the number of marked traces, number of nodes, number of edges, and the sum of the probabilities.
* For generated diagrams, the number of diagrams generated for each of the seven diagram types.
Here is an example spreadsheet view. Because it is wide, it is shown in two pages:
CSV logs are created in the directory that `test.py` is run from. The filename includes the time the test was started and is of the form `_test_log_<timestamp>.csv`.
#### Trace and global view graphs
Graphs allow visual inspection of every trace and global view generated. While the CSV log quantifies graph components, useful for detecting change, graph views enable visual inspection of graph component associations.
A graph of each trace is generated in directory `_test_graphs` in the directory that `test.py` is run from. Each graph is named by its schema and theree-digit graph number as follows: `<schema name>_<graph number>.png`.
#### Runtime status
Runtime status indicates the index and name of the .mp code file currently being worked on. Runtime status will also show runtime errors.
# Code
# Submitting Pull Requests
Please submit code by submitting pull requests. Here is the basic workflow:
* Clone the Gryphon repository.
* Create a branch for your work.
* Add your code.
* Submit a pull request.
Gryphon version control and code management is performed using Git. For references on using Git please see https://git-scm.com/doc. In our examples we describe working with Git from a Linux command prompt. We will use Linux file and directory commands.
We access NPS GitLab using Git commands. To enable key-managed SSH authentication with the NPS GitLab Server please install your RSA Public key, see https://gitlab.nps.edu/-/profile/keys.
For demonstration, we will work with a clone of the Gryphon repository that we will install under folder `gitlab`. We create this work folder in our home directory by typing:
mkdir ~/gitlab
## Clone the Gryphon repository.
Please set up GitLab with your SSH RSA key and please set up a working directory on your local machine as described above, and then clone the Gryphon repository:
When you clone a repository, it places you on the "master" branch. Rather than working directly on the master branch, create a new branch and do your work there. For example to start work on new branch "my fix", type:
cd ~/gitlab/gryphon
git checkout -b "my fix"
## Add code
Add code, make changes, etc. To see changed files:
git status
Here you may see files indicated as changed or new. To see specific changes, type:
git diff
When ready, stage these changes for inclusion into your "my fix" branch. For example stage file "my_new_file.py":
git add my_new_file.py
Now typing `git status` will show that files are staged on the "my_fix" branch. Commit these changes to the "my fix" branch. Include a statement about the change:
git commit -m "fix misleading wording"
This commits your change to your clone of the repository, but it does not push your change upstream to the NPS GitLab Server. For that, push your branch upstream to the origin:
git push -u origin "my fix"
## Submit a pull request
Once your branch is uploaded, create a pull request on GitLab (GitLab calls this a merge request). For detail please see https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html.
* From your browser, open the NPS GitLab repository at https://gitlab.nps.edu/monterey-phoenix/user-interfaces/gryphon/-/tree/master
* Verify that your branch is there: near the upper-left, click the drop-down indicating "master" to reveal the branches and tags. You should see your "my fix" branch.
* At the left, click on "Merge requests" to initiate your merge request. Here, select your source branch; the target branch is "master". Click "Compare branches and continue". A "New merge request" page opens.
* Fill in the form. For Description, please include details to help us understand any specific details about the request. Please also provide steps for testing to help with validating expected behavior. Then click "Create merge request".
* At this point, your merge request is submitted and shows up in the merge list under "Merge requests" in the GitLab repository's home at https://gitlab.nps.edu/monterey-phoenix/user-interfaces/gryphon/-/tree/master.
Gryphon version control and code management is performed using Git. For references on using Git please see https://git-scm.com/doc. To enable key-managed SSH authentication with the NPS GitLab Server please install your RSA Public key, see https://gitlab.nps.edu/-/profile/keys.
## Merging pull requests into master
* An assigned developer will review your pull request and may ask questions or request changes.
* Once reviewed, the assigned developer may click "approve" to approve the pull request, after which it may be merged into master.
* Before merging, though, be sure that the branch is up to date with master. If it is not, there may be change conflicts and the merge operation will be denied. Before merging, issue "git pull" to bring the branch up to date with master. Then merge the branch.
