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

Creating C and Python bindings for all functionality used by Repl. Refactoring Repl to call through Python by default #450

Merged
merged 34 commits into from
Oct 20, 2023

Conversation

luketpeterson
Copy link
Contributor

@luketpeterson luketpeterson commented Oct 2, 2023

Creating C and Python bindings for all functionality used by Repl.
Refactoring Repl to call through Python by default.

Changes include:

  • Adding Environment object to Rust, C & Python for non-interactive configuration management (module search paths, config files, etc.)
  • Adding SyntaxNode parsing API to C & Python
  • Adding RunnerState / incremental MeTTa runner API to C & Python
  • Adding parse error accessor to C & Python, instead of panicking on invalid syntax
  • Refactoring REPL app, so that it calls MeTTa through Python by default. NOTE: I am preserving the direct Rust path for the "no_python" path because I plan to unify the "python" and "no_python" paths in the future, once we can link HyperonPy in a static build. (when we address PyO3 as alternative Python binding  #283)
  • Changing REPL default to Python, and requiring explicit "no_python" feature to build REPL without Python dependency
  • Removing ctor to initialize logger, because it makes sense to init the logger from the environment initialization

@luketpeterson luketpeterson requested a review from vsbogd October 2, 2023 07:35
@luketpeterson
Copy link
Contributor Author

This PR should address:
#439
#386
#301

And perhaps others.

Copy link
Collaborator

@vsbogd vsbogd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Luke, thanks for the such amount of work. Didn't look at the REPL code changes yet, but posting current comments to not slow this down.

lib/src/metta/environment.rs Outdated Show resolved Hide resolved
lib/src/metta/environment.rs Outdated Show resolved Hide resolved
python/hyperon/base.py Outdated Show resolved Hide resolved
python/hyperon/atoms.py Outdated Show resolved Hide resolved
python/tests/scripts/f1_imports.metta Outdated Show resolved Hide resolved
lib/src/metta/runner/mod.rs Show resolved Hide resolved
lib/src/lib.rs Show resolved Hide resolved
python/hyperon/runner.py Show resolved Hide resolved
c/src/metta.rs Outdated Show resolved Hide resolved
c/src/metta.rs Outdated Show resolved Hide resolved
luketpeterson and others added 6 commits October 3, 2023 14:52
…ly fail

Reworking C API to use builder object, rather than relying on a static state.  This allows flexibility to initialize the environment from multiple threads - although that is still ugly and discouraged
…vironments to be initialized and used from C & Python layers
Copy link
Collaborator

@vsbogd vsbogd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Luke, I am very sorry for a late review. Thanks for adding ability to initialize runner with instance of the environment 👍 I propose to go further with fixing the rest of comments and merging it.

One major question to me here is should we keep some shared instance of the environment or just replace it by asking user to create a default instance if it is needed?

lib/src/metta/environment.rs Outdated Show resolved Hide resolved
lib/src/metta/environment.rs Outdated Show resolved Hide resolved
///
/// NOTE: If `env_builder` is `None`, the platform environment will be used
/// NOTE: This function does not load any stdlib atoms, nor run the [Environment]'s 'init.metta'
pub fn new_with_space(space: DynSpace, tokenizer: Shared<Tokenizer>, env_builder: Option<EnvBuilder>) -> Self {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you intentionally use EnvBuilder instead of Environment here? We could also pass a Builder a Environment instance here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. I felt like having the built environment in an owned state complicated the API (especially in other languages) without much gain.

So now Environment is like Path; ie. the API user can have access &Environment references, and call methods on it, but they can't own a naked Environment outside the hyperon crate.

python/hyperon/runner.py Show resolved Hide resolved
lib/src/metta/runner/mod.rs Outdated Show resolved Hide resolved
luketpeterson and others added 6 commits October 11, 2023 13:06
…vec_t with a Python list of atoms

Changing `sexpr_parser_t` from wrapped Shared ptr to wrapped Box
Changing RunnerState API to take ownership of the parser and, rather than asking the caller to provide the parser each step.  There is no good reason to switch parsers with the same RunnerState and switching them is just asking for bugs
Adding “with_atoms” alternative to create a RunnerState
…se.py, because error expressions are not part of the core MeTTa spec
…APIs, and adding some infrastructure around error expression atoms
@luketpeterson
Copy link
Contributor Author

I believe I have addressed all of the feedback in this PR.

The only remaining issue is whether or not runner.load_py_module_from_path should be private, and any new issues resulting from the changes I made.

lib/src/metta/runner/mod.rs Outdated Show resolved Hide resolved
None => EMPTY_SYMBOL,
};
if let Some(err_code) = err_code {
Atom::expr([ERROR_SYMBOL, err_atom, err_code, Atom::sym(message)])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment Error expressions use only two arguments: first is atom and second one is either error code or custom message. Also atom is required argument. Which use-cases do you have in mind for the changes made?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was that sometimes both an err_code and a custom message are desirable. The caller can branch on an err code in a way that they can't reliably branch on a human-readable message. But a human-readable message can specify additional information, including composing a message with specific details about the error.


//QUESTION: These functions below seem to only be used in tests. If that's the case, should we
// move them into a test-only module so they aren't exposed as part of the public API?
//Alternatively rewrite the tests to use a runner?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please move them into a test-only module for now. There is no much sense in re-writing these tests, they will vanish after migration to the minimal interpreter.

c/src/metta.rs Outdated Show resolved Hide resolved
python/tests/test_extend.py Show resolved Hide resolved
vsbogd
vsbogd previously approved these changes Oct 18, 2023
Copy link
Collaborator

@vsbogd vsbogd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Luke, I approved it, please feel free to merge when you are ready.

@luketpeterson
Copy link
Contributor Author

I think this is ready for merge after these fixes. As discussed, I'll take care of the extraneous API in the metta/mod.rs file in a separate PR.

@vsbogd vsbogd merged commit 738e739 into trueagi-io:main Oct 20, 2023
1 check passed
@vsbogd
Copy link
Collaborator

vsbogd commented Oct 20, 2023

Thanks Luke, I merged it

@Necr0x0Der
Copy link
Collaborator

Thanks Luke. Looks cool and working!

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.

3 participants