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

CLI support #47

Open
13 tasks
garfieldnate opened this issue Mar 5, 2025 · 2 comments
Open
13 tasks

CLI support #47

garfieldnate opened this issue Mar 5, 2025 · 2 comments

Comments

@garfieldnate
Copy link
Contributor

garfieldnate commented Mar 5, 2025

To make the power of V-S accessible in contexts where users cannot or do not want to open the actual editor, CLI support for the various project actions would be very useful. I'm thinking of CI, in particular, where we could run datamap validation on every commit, but it would also become accessible for plugins in other editors. You could think of this is a baby version of the LSP idea that already provides a lot of value.

  • CLI entry point with help output
  • Check that project file(s) are well-formed
  • Check all productions against datamap
  • Check all productions for syntax errors
  • Verify subtree (for specific DM node or for all foreign DM nodes)
  • Re-import subtree (for specific DM node or for all foreign DM nodes)
  • Search DM for WMEs that are never tested
  • Search DM for WMEs that are never created
  • Search DM for WMEs that are tested but never created
  • Search DM for WMEs that are created but never tested
  • Search DM for WMEs that are never created or tested
  • Generate datamap from current operator hierarchy
  • Auto-complete at a position in a production

For my current purposes I really only care about the top few on the list, but I've listed what I think are all of the potentially useful commands.

I would set the return code to 0 for no issues found, 1 for some found, -1 for an execution error of some kind (unparseable project file, etc). Some of the later actions in the list might not actually be "errors", per se, so perhaps we should make this configurable.

I would print the resulting validation warnings/errors to stdout, and execution errors to stderr.

I would give the user the option to output in JSON for ingestion in other tools.

@garfieldnate
Copy link
Contributor Author

garfieldnate commented Mar 6, 2025

Examining the code for the various actions, it seems that V-S actually re-parses the project's Soar productions each time one of the actions is executed, rather than storing any incremental representation and updating when the user changes the productions. That's interesting to me because it means that performance-wise there is very little advantage to creating an LSP; it would save the time of parsing and loading the project itself, but not of re-parsing the productions after edits. It would still be useful for syntax highlighting and for more easily plugging into supported editors, but I'm happy to know that the CLI option won't be much less performant.

@garfieldnate
Copy link
Contributor Author

garfieldnate commented Mar 6, 2025

We should ensure that none of the commands run the DM compaction, which deletes unreachable parts of the DM. We could perhaps add it as a separate command, but it's not something I want too authors to accidentally run, as it could lose important work.

Also, I thought that V-S would edit productions automatically when an attribute name in the DM is updated, but that is not the case as far as I can tell. Same with, for example, moving a DM node to a different folder. So are there no supported refactors? There's also no functionality to jump from some text in a production to the entry in the DM that matches it.

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

No branches or pull requests

1 participant